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INTRODUCTION 


I  . 

Acolytes  of  object-oriented  (00)  concepts  and 
methodologies  maintain  that  this  new  approach  to  software 
development  promises  to  be  more  than  just  another  set  of 
programming  languages.  Rather,  it  represents  a  comprehensive 
philosophy  for  planning,  designing,  and  implementing  solutions 
to  complex  problems.  An  explosion  of  articles,  magazines, 
books,  and  conferences  dedicated  to  exploring  and  popularizing 
00  techniques  occurred  during  the  1980' s.  This  concentration 
of  effort  notwithstanding,  the  00  philosophy  has  yet  to  arrive 
at  a  consolidated  point-of-view  on  many  fundamental  concepts. 

The  objective  of  this  thesis  is  to  review  the  potential 
benefits  of  00  techniques,  to  define  fundamental  00  concepts, 
to  advance  recommendations  for  organizing  00  design,  and  to 
demonstrate  conflicts  among  00  mechanisms  that  dilute  the 
favorable  properties  ascribed  to  object-oriented  programming 
(OOP)  . 

The  beneficial  properties  of  the  00  approach  to  software 
development  are  briefly  reviewed  in  this  chapter.  These 
properties  are  commonly  viewed  as  desirable  from  the 
perspective  of  software  engineering.  Not  all  the  properties 
are  unique  to  the  00  philosophy,  much  less  common  to  all 
object-oriented  programming  languages  (OOPLs) .  Nevertheless, 
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the  00  philosophy  represents  a  comprehensive  attempt  at 
integrating  all  the  concepts  and  facilities  affecting  the 
software  lifecycle  in  a  fashion  that  enhances  the  desirable 
properties . 

A.  COMPLEXITY  MANAGEMENT 

Software  development  increasingly  occurs  in  an  industrial 
setting  typified  by  product  complexity,  system  longevity,  and 
incessant  product  evolution.  (Jacobson,  1991)  00  techniques 
have  been  employed  for  developing  complex  software  products 
such  as  compilers,  databases,  computer  aided  design  (CAD) 
systems,  simulations,  meta  models,  operating  systems, 
spreadsheets,  signal  processors,  and  control  systems. 
(Rumbaugh,  1991)  Development  of  such  complex  systems  requires 
architectures,  methods,  and  processes  that  divide  system 
development  into  smaller  parts  and  that  can  handle  change 
efficiently.  (Jacobson,  1991)  The  following  subsections  list 
desirable  software  features  which  the  00  approach  to  software 
development  attempts  to  innovate,  thus  making  it  well  suited 
for  managing  complex  application  problems. 

1 .  Abstraction 

Abstraction  is  used  to  simplify  the  design  of  a 
complex  system  by  reducing  the  number  of  details  that 
must  be  considered  at  the  same  time.  (Berzins,  1991, 
pg.  7  9) 

Abstraction  is  an  intellectual  process  that 
facilitates  the  comprehension  of  complex  entities  and 
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processes  through  simplification.  This  simplification  allows 
knowledge  to  be  expressed  as  generalized,  essential 
information  which  can  be  absorbed  and  understood  by  human 
beings , 


The  level  of  detail  necessary  to  formulate  an 
abstraction  varies  with  the  requirements  of  the  problem. 

(Booch,  1987)  In  the  context  of  00  analysis,  design,  and 
programming,  abstraction  focuses  attention  on  the  behaviors 
and  attributes  of  objects  rather  than  on  the  implementation 
details  (which  vary  from  one  language  to  another)  .  This 
method  of  thinking  about  problem  entities  allows  problems  to 
be  pursued  as  successive  refinements,  with  each  refinement 
constituting  an  abstraction  manifesting  a  particular  level  of 
detail.  Hence,  designs  and  programs  can  be  conceived  of  as 
multileveled  structures  of  abstractions. 

2 .  Information  Hiding 

Information  hiding  emphasizes  the  need  to  separate 
function  from  implementation .  Apart  from  continuity, 
it  is  also  related  to  the  requirements  of 
decomposability,  compos  ability  and  under standabil it y : 
to  separately  develop  the  modules  of  a  system,  to 
combine  various  existing  modules,  or  to  understand 
individual  modules,  it  is  indispensable  to  know  what 
each  of  them  may  and  may  not  expect  from  the  others. 
(Meyer,  1988,  pg.  23) 

Information  hiding*  is  a  technique  for  minimizing 
interdependencies  among  separately  written  modules.  (Snyder, 


^Sometimes  termed  encapsulation  in  the  OO  literature. 
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1986)  Knowledge  about  data  structure  and  function 

implementation  is  kept  private  by  forcing  interaction  with 
these  structures  through  an  external  interface.  In  the  wider 
context  of  software  development,  information  hiding  promotes 
the  independent  construction  of  cooperating  modules,  and,  most 
importantly,  isolates  the  effects  of  implementation 
modification  to  the  affected  module.  So  long  as  external 
interfaces  are  stable,  implementation  details  can  be  modified 
without  impinging  upon  users  of  the  interface.  Hence, 
software  maintenance  becomes  localized,  no  longer  a  perilous 
search  for  linkages  in  interrelated  program  modules,  with 
consequent  economies  in  time,  human,  and  onetary  resources. 

Information  hiding  is  a  critical  metric  of  any  OOPL. 
Consequently,  individual  OOPLs  should  be  studied  to  determine 
the  degree  to  which  information  hiding  is  enforced. 

3 .  Reusability 

Reuse  may  be  defined  as  the  effective  ability  to 
incorporate  objects  created  for  one  software  system 
into  a  different  software  system.  The  essence  of 
reuse  is  the  ability  to  take  all  or  part  of  a  product 
and  completely  and  correctly  embed  it  within  a  new 
product  that  may  be  constituted  and  structured  quite 
differently .  (Wasserman,  1991,  pg.  55) 

Reusability  clearly  coincides  with  'why  reinvent  the 

wheel'  modes  of  thinking.  Even  limited  software  development 

experience  is  enough  for  one  to  notice  that  programs  exhibit 

pervasive  commonalities  with  respect  to  algorithms,  data 

structures,  and  functions.  Reusability  is  a  language  property 
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that  allows  previously  developed  software  to  be  readily 
incorporated  into  new  software.  Two  substantial  benefits  flow 
from  reuse:  (1)  development  effort  is  reduced/  and,  (2)  reused 
code  has  (presumably)  been  tested  and  verified^. 

The  principal  00  mechanisms  for  achieving  reuse  are 
inheritance,  polymorphism,  and  dynamic  binding.  Much  of  the 
value  of  programming  in  the  00  environment  arises  from  the 
capability  to  use  previously  developed  code  stored  in  software 
libraries.  Developers  may  also  be  familiar  with  a  problem's 
requirements  and  important  abstractions;  consequently, 
opportunities  for  reusing  not  only  software,  but  entire 
designs  and  requirements  also  exist.  (Booch,  1991) 

4 .  Extandibility 

Extendibility  is  the  ease  with  which  software  products 
may  be  adapted  to  changes  in  requirements .  (Meyer, 
1988,  pg.  5) 

Extendibility  is  a  concept  allied  to,  but  distinct 
from,  reusability.  It  encompasses  those  properties/mechanisms 
which  enable  new  code  to  be  developed  as  extensions  to 
previously  written  code.  Extendibility  assumes  greater 
importance  as  problem  understanding  improves,  resulting  in  new 
requirements.  As  program  scale  grows,  extendibility  is  best 
achieved  through  design  simplicity  and  modular 


^This  does  not,  however,  relieve  developers  of  the  burden 
of  ensuring  that  borrowed  code  still  functions  properly  in  its 
new  environment.  (Perry,  1990) 
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decentralization.  (Meyer,  1988)  In  the  00  environment, 
extendibility  is  realized  through  the  application  of 
inheritance  technicjues  to  class  definitions  in  class 
hierarchies . 

5 .  Maintainability 

A  designer  endeavors  to  organize  a  design  so  that  it 
is  resilient  to  change/  a  packaging  that  will  remain 
stable  over  time  is  sought.  The  answer  is  to  separate 
those  parts  of  the  system  that  are  intrinsically 
volatile  from  those  parts  that  are  likely  to  be 
stable.  (Coad  and  Yourdon,  1991,  pg.  15) 

Maintainability  is  principally  an  economic  concept. 

It  refers  to  the  efficiency  by  which  modifications  can  be 

introduced  over  the  software  lifecycle.  Technically, 

maintainability  concerns  the  degree  to  which  linkages  in 

program  elements  magnify  the  effects  of  modifications. 

Economically,  maintainability  reflects  the  cost  required  to 

correct  bugs,  to  modify  code,  or  to  extend  code.  The  primary 

cost  is  the  human  effort  required  to  police  change.  Software 

which  collectively  exhibits  strong  abstraction,  information 

hiding,  reusability,  and  extendibility  generally  manifest 

favorable  maintainability  properties. 

B .  THESIS  MOTIVATION 

In  point  of  fact,  the  lack  of  a  standardized  conceptual 
foundation  for  many  00  ideas  has  resulted  in  an  uneven  record 
with  respect  to  the  completeness  with  which  individual  OOPLs 
contribute  toward  achieving  a  unified  realization  of  the 
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beneficial  software  properties.  One  of  the  purposes  of  this 
thesis  is  to  indicate  the  mapping  of  fundamental  00  concepts 
to  abstraction,  information  hiding,  reusability, 
extendibility ,  and  maintainability.  Given  these  associations, 
it  is  possible  to  investigate  how  the  interactions  of  language 
mechanisms  which  engineer  the  fundamental  00  concepts  can 
mitigate  the  desirable  properties  should  potential  conflicts 
not  be  thoroughly  understood.  A  primary  objective,  therefore, 
is  to  facilitate  better  00  software  development  by 
acknowledging  that  conflicts  exist  which  must  be  accounted  for 
during  analysis,  design,  implementation,  and  maintenance. 

C.  THESIS  ORGANIZATION 

Chapter  II  surveys  the  00  literature  in  attempting  to 
formulate  definitions  for  fundamental  00  concepts.  Chapter 
III  draws  upon  the  00  literature  to  advance  recommendations 
for  conducting  object-oriented  analysis  (OOA)  and  object- 
oriented  design  (OOD) .  Chapter  IV  examines  connections 
between  functional  decomposition  and  subclass  responsibility. 
Chapter  V  furthers  the  aims  of  Chapter  III  by  investigating 
two  major  00  problems:  (1)  conflicts  between  information 
hiding  and  inheritance  mechanisms;  and,  (2)  design  conflicts 
between  composition  and  inheritance.  Finally,  Chapter  VI 
offers  conclusions  and  suggestions  for  further  research. 
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II.  FUNDAMENTAL  OBJECT-ORIENTED  CONCEPTS 


00  methodology  is  occasionally  presented  as  a  Kuhnian 
paradigm  by  which  is  meant  a  corpus  of  scientific  work  which 
"...defines  the  legitimate  problems  and  methods  of  a  research 
field  for  succeeding  generations  of  practitioners."  (Kuhn, 
1962,  pg.  10)  Budd  accepts  this  departure  point,  adding  that 
the  00  paradigm  "...  forces  us  to  reconsider  our  thinking  about 
computation,  about  what  it  means  to  perform  computation,  about 
how  information  should  be  structured  within  a  computer." 
(Budd,  1991,  pg.  3)  Essentially,  then,  the  00  paradigm  is 
about  knowledge  representation  in  the  computer  environment. 
From  this  perspective,  00  methodology  constitutes  a  new  way  of 
conceptualizing  and  solving  the  problems  of  software 
engineering . 

Although  there  currently  exist  no  00  standards  for  00 
language  designers  to  observe,  considerable  consensus  exists 
as  to  the  primary  concepts  which  formulate  the  00  paradigm. 
Nevertheless,  there  remains  sufficient  semantic  variation  in 
the  literature  to  warrant  a  thorough  review  of  these  concepts. 
The  balance  of  this  chapter  surveys  the  00  literature  with  the 
intent  of  arriving  at  definitions  of  fundamental  concepts  for 
use  in  succeeding  chapters. 
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A .  OBJECTS 


Objects  occupy  a  curious  dual  status.  Often,  they  are 
introduced  in  anthropomorphic  terms  as  the  entities  (physical 
or  ideational)  in  the  problem  domain.  Alternatively,  they  are 
presented  as  the  primary  programming  constructs  in  00 
languages;  constructs  which  'closely'  parallel  the  entities  in 
the  problem  domain.  Although  the  differences  between  the  two 
views  are  minimal  in  terms  of  practical  consequences  for  00 
analysis  and  design,  the  distinction  should  be  bourn  in  mind 
since  the  latter  emphasizes  that  objects  are  constrained  not 
only  by  their  real-world  possibilities  but  also  by  the 
capabilities  of  computers  and  programming  languages. 

1 .  Definition 

Objects  encapsulate  both  state  and  behavior . (Halbert 
and  O'Brien,  1987,  pg.  72) 

Objects  are  entities  that  combine  the  properties  of 
procedures  and  data  since  they  perform  computations 
and  save  local  state.  (Stefik  and  Bobrow,  1986, pg.  41) 

An  object  has  state,  behavior,  and  identity;  the 
structure  and  behavior  of  similar  objects  are  defined 
by  their  common  characteristics ;  the  terms  instance 
and  object  are  interchangeable.  (Booch,1991,  pg.  77) 

Objects  are  autonomous  entities  that  respond  to 
messages  or  operations  and  share  a  state. 
(Wegner, 1987,  pg.  168) 

Several  salient  points  can  be  drawn  from  these 
definitions.  First,  objects  have  a  structure  (representation), 
which  preserves  the  state  of  an  object.  An  object  may 
manifest  many  states  over  the  course  of  its  existence  (i.e., 
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its  state  may  change);  hence,  objects  can  have  a  history. 
Second,  objects  exhibit  observable  behavior.  Objects 
communicate  with  one  another  by  passing  messages  to  elicit 
needed  behavior^.  Third,  objects  have,  in  some  sense,  an 
existential  status  that  uniquely  distinguishes  each  object 
from  all  others.  This  status  is  usually  termed  identity. 
Fourth,  the  fact  that  an  object  has  an  identity  and  can  have 
a  history  implies  that  it  can  exist  beyond  the  lifetime  of  the 
program (s)  in  which  the  object  may  have  been  created  or  used. 
This  quality  is  termed  persistence.  (Loomis,  1991) 

A  few  clarifications  are  in  ord^'r.  Objects  can  be 
created  that  do  not  have  a  structure  However,  it  is 
difficult  to  isolate  what  distinguishes  these  entities  from 
procedures,  and  calls  into  question  the  existential  status  of 
such  entities  -  that  is,  must  not  there  be  a  'some'  for  an 
object  to  be  something?  Behavior  is  the  set  of  actions  an 
object  can  undertake.  In  the  context  of  a  program,  an  object 
sends  a  message  to  another  object  (or  itself)  requesting  a 


^Message-passing  is  one  mechanism  for  managing  object 
communication.  Messages  are  sent  "...to  an  object  to  tell  it 
to  perform  one  of  its  methods."  (Nelson,  1991,  pg.  4) 
Messages  are  essentially  legal  invocations  of  methods 
(behaviors)  associated  with  objects.  Legal  invocations  are 
those  made  to  methods  which  objects  have  made  availeible.  Note 
that  not  every  OOPL  utilizes  message-passing  as  the  mechanism 
for  inter-object  communication.  CLOS  (Keene,  1989) ,  for 
example,  uses  generic  function  calls.  This  sometimes  leads  to 
what  is  called  the  "message  passing  paradigm"  in  which  ". . .the 
only  way  to  access  an  object  or  any  of  its  variables  is  by 
sending  it  a  message."  (Nelson,  1991,  pg.  4) 
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service  offered  by  the  receiving  object.  The  receiving  object 
determines  how  best  to  comply  with  the  request,  selecting 
among  a  set  of  methods  (operations)  which  satisfy  the  request, 
responding  in  a  form  that  the  sender  can  understand  and  use. 
Hence,  there  is  a  semantic  quality  to  behavior.  Note  that 
much  of  the  versatility  and  confusion  in  00  programming  arises 
from  the  mechanisms  that  determine  which  object  receives  a 
request  and  which  method  is  selected. 

2 .  Identity 

As  stated  in  the  introduction  to  this  chapter,  the  00 
paradigm  constitutes  a  new  approach  to  representing  knowledge 
in  the  computer  environment.  Specifically,  objects,  as 
programming  constructs,  achieve  a  sufficiently  elevated  level 
of  abstraction  so  as  to  closely  parallel  their  real-world 
counterparts.  Real-world  entities  are  bounded  and 
distinguishable.  In  the  computer  environment  this  recfuires 
"...the  ability  to  distinguish  objects  from  one  another 
regardless  of  their  content,  location  or  addressability,  and 
to  be  able  to  share  objects.  Object  identity  enables  us  to 
realize  this  goal."  (Khoshafian  and  Copeland,  1986,  pg . 
406) 

The  practical  consequence  is  that  an  00  language 
should  preserve  this  existential  status  as  an  independent  fact 
about  objects.  This  existential  status  can  be  described  as 
the  space  (which  is  relocatable)  in  any  memory  which  the 
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object  happens  to  occupy.  It  can  be  argued  that  an  00 
language  must  maintain  identity  despite  changes  in  an  object's 
state,  address,  or  user-defined  name,  and  throughout  its 
lifetime.  (Khoshafian  and  Copeland,  1986)  An  00  language 
accomplishes  this  best  by  maintaining  a  built-in  identifier 
for  an  object  that  (presumably)  does  not  change.  "The  failure 
to  recognize  the  difference  between  the  name  of  an  object  and 
1-he  object  itself  is  the  source  of  many  kinds  of  errors  in 
object-oriented  programming."  (Booch,  1991,  pg .  84)  These 

errors  include  assignment  operations  which  orphan  objects", 
aliasing  through  assignment  (structural  sharing) ,  and 
inappropriate  semantics  for  equality  operators.  (Booch,  1991) 
3 .  Persistence 

An  object  is  created,  persists  for  some  period  of 
time,  and  can  be  destroyed.  Its  lifetime  may  be  less  than, 
parallel  to,  or  exceed  that  of  the  program  in  which  it  is 
created.  This  last  possibility  represents  a  database  issue  in 
general,  but  with  particular  refinements  for  objects;  the 
identity  and  nature  (class  of  which  it  is  an  instance)  of  an 
object  must  be  preserved  along  with  its  state. 


^For  example,  the  assignment  object_x  :=  object_y  renders 
inaccessible  the  original  object  for  which  ob ject_x  was  the 
name . 


12 


4  .  Conceptual  Distinction?? 

a.  Objects  and  Programs 

The  00  paradigm  leads  the  programmer  to  an 
entirely  different  perspective  on  program  construction.  What 
has  been  described  as  the  traditional  imperative  approach  to 
programming  consists  of  procedural  modules  which  act  on  data. 
This  perspective  leads  to  a  top-down,  functional  decomposition 
of  programs.  00  programs  consist  of  objects  acting 

cooperatively,  but  autonomously.  Cooperative  behavior  can 
achieve  various  levels  of  integration,  producing  system 
behavior  at  the  highest  levels.  The  great  strength  of  this 
approach  is  the  comparative  ease  with  which  complex  systems 
can  be  modeled  as  interacting  objects. 

b.  Objects  and  Data 

Objects  are  not  simply  data  structures.  It  is 
important  to  recognize  that  objects  are  entities  which 
manifest  both  structure  and  behavior.  Moreover,  the 

implementation  of  an  object's  structure  should  be  hidden  from 
other  objects  (i.e.,  encapsulated)  for  the  reasons  outlined  in 
Chapter  I.  This  is  not  the  case  for  data  driven  programs  in 
which  data  structures  are  globally  accessed  and  modified. 

c.  Objects  and  Equality 

Object  identity  necessitates  reviewing  in  what 
respect  objects  can  be  said  to  be  equal.  Database 
applications  may  require  that  relational  comparisons  be 
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available.  (Nelson,  Moshell,  and  Orocji,  1990) 
languages  allow  programmers  to  generate  operations  for 
determining  equality.  Variations  include  reference  identity 
in  which  references  point  to  the  same  object,  and  structural 
identity  in  which  corresponding  parts  of  objects  have  the  same 
value.  It  is  worth  noting  that  the  semantics  of  equality  and 
relational  operators  in  this  context  do  not  necessarily  follow 
the  use  of  normal  logic  -  objects  can  at  once  be  not  greater 
than,  not  equal  to,  and  not  less  than  one  another^.  (Nelson, 
Moshell,  and  Orooji,  1990) 

B .  CLASSES 

A  major  milestone  in  the  evolution  of  software  engineering 
has  been  the  modularization  of  software  components.  Berzins 
and  Luqi  define  a  moaule  as  a  "...conceptual  unit  in  a 
software  system  that  corresponds  to  a  clearly  identifiable 
region  of  the  program  text."  (Berzins  and  Luqi,  1991,  pg.  13) 
From  this  perspective,  modularization  is  a  facet  of  software 
construction  which  produces  "...software  systems  made  of 
autonomous  elements  connected  by  a  coherent,  simple 
structure."  (Meyer,  1988,  pg.  11) 

Actual  modular  elements  will  vary  among  programming 
languages;  the  essential  aspect  of  modularization  is  that  it 

^Nelson,  Moshell,  and  Orooji  suggest  that  there  are 
contexts  in  which  "...it  is  inappropriate  to  say  that  one 
object  is  greater  than  or  less  than  another."  (Nelson, 
Moshell,  and  Orooji,  1990,  pg .  321) 
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promotes  conceptual  localization  of  code.  This  localization 
can  be  exploited  to  realize  other  desirable  software 
properties  including  data  abstraction,  encapsulation, 
reusability,  extendibility ,  reliability,  and  maintainability . 

Classes  are  the  key  modules  in  most  00  languages.  Note 
that  this  position  is  taken  in  view  of  the  fact  that  objects 
are  declared  as  instances  of  classes.  It  is  perhaps  more 
accurate  to  state  that  classes  are  the  key  design  modules  and 
objects,  as  instances  of  classes,  are  the  key  program  modules. 

Most  00  languages  provide  for  classes,  although  a  few  do 
not.  The  various  languages  utilizing  classes  do  so  for 
different  purposes,  depending  upon  their  overall  philosophy. 
This  section  surveys  the  differing  uses  for  classes. 

1 .  Definition 

A  class  is  a  template  (cookie  cutter)  from  which 
objects  may  be  created  by  'create'  or  'new' 
operations.  Objects  of  the  same  class  have  common 
operations  and  therefore  uniform  behavior .  (Wegner, 
1987,  pg.  169) 

A  class  is  a  description  of  one  or  more  similar 
objects.  In  comparison  to  procedural  programming 
languages r  classes  correspond  to  types.  (Stefik  and 
Bobrow,  1986,  pg .  42) 

Whereas  an  object  is  a  concrete  entity  that  exists  in 
time  and  space,  a  class  represents  only  an 
abstraction,  the  'essence'  of  an  object,  as  it  were. 
(Booch,  1991,  pg.  93) 

A  class  should  allow  you  to  build  a  taxonomy  of 
objects  on  an  abstract,  conceptual  level.  (Wirfs- 
Brock,  Wilkerson,  and  Wiener,  1990,  pg .  22) 
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An  object  manifests  structure  and  behavior.  Groups  of 
objects  may  display  common  structure  and  behaviors  which  can 
be  abstracted  into  class  definitions'*.  Once  an  object  is 
identified  (declared)  as  belonging  to  a  particular  class,  its 
structure  and  behavior  can  be  delimited  according  to  that 
common  definition.  This  contributes  powerfully  toward 
reusability:  individual  objects  acquire  definition  from  an 
existing  class  'template'. 

A  class  typically  consists  of  variables  whose  values 
are  either  defined  individually  for  each  object  (instance 
variables),  or  are  defined  in  the  class  definition  itself  as 
belonging  to  all  instances  (class  variab  es) ,  and  of  methods 
which  define  behavior  appropriate  to  instances  of  the  class. 
Some  of  the  methods  in  a  class  are  auxiliary  in  the  sense  that 
they  carry  out  operations  needed  by  other  methods,  but  d(  not 
themselves  correspond  to  abstractions  which  are  observable. 


^Odell  presents  a  philosophical  analysis  of  classes  that 
begins  with  describing  cognitive  categories  for  discussing 
knowledge  and  knowledge  acquisition.  (Odell,  1991)  His 
principle  point  is  that  humans  formulate  their  understanding 
of  objects  as  concepts,  and  it  is  these  concepts  which  are 
used  to  build  classes.  Concepts  can  have  a  name 
(representative  symbol) ,  an  intension  (definition) ,  and  an 
extension  (the  group  of  objects  the  concept  applies  to)  .  Note 
that  this  way  of  viewing  classes  does  not  require  that  OOP 
objects  parallel  real-world  objects  so  much  as  that  they 
parallel  human  cognition  of  these  objects.  Moreover,  this 
view  also  lends  itself  to  defining  'unreal'  or  imaginary 
objects . 
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These  auxiliary  methods  are  a  form  of  ’-nowledge  about  class 
instances  which  users  do  not  need  to  know. 

An  interface  to  a  class  consists  of  those  variables 
and  methods  which  are  visible  to  other  objects  and  to 
subclasses  (defined  in  Chapter  Il/Section  3)^.  The  interface 
available  to  other  objects  is  called  the  "external  view"  and 
the  interface  available  to  subclasses  is  called  the  "internal 
view."^  (Micallef,  1988,  pg .  13) 

Not  every  OOPL  offers  a  means  for  limiting  the  various 
interface  visibilities.  Those  that  do  (C++,  for  example) 
provide  mechanisms  for  enforcing  private  and  public 
distinctions.  Private  variables  and  methods  represent 
knowledge  that  is  not  known  by  other  objects,  and  therefore 
are  not  part  of  the  external  or  the  internal  interface. 
Public  variables  and  methods  are  known  and  integrated  into  the 
external  and  internal  interfaces.  Generally,  encapsulation  is 
best  enforced  if  variables  are  kept  private,  accessible  only 
through  public  methods.  An  additional  level  of  control  can  be 
applied  to  the  internal  interface:  variables  or  methods  can  be 


^An  interface  can  also  be  viewed  as  the  set  of  behaviors 
an  object  makes  available  for  use  by  other  objects. 

*Note  that  a  third  interface  to  new  objects  is  sometimes 
mentioned  in  the  00  literature.  (Micallef,  1988)  This 
interface  involves  decisions  about  the  external  interface, 
initialization  procedures,  and  class  variables  which  will  be 
made  available  to  instantiations  of  a  class.  Also,  the 
various  views  are  called  interfaces  (for  example,  the  external 
view  is  the  same  as  the  external  interface) . 
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declared  protected  which  renders  them  visible  to  subclasses 
but  not  to  other  objects^. 

As  previously  noted,  classes  also  constitute  the  key 
modules  in  most  00  languages.  Class  modularity  serves  the 
objectives  stated  above  and  will  be  explored  in  the  following 
subsections.  The  capability  of  classes  to  serve  as  a  pattern 
for  object  declaration  ensures  consistent  realization  of  these 
objectives  in  an  00  program. 

2 .  Classes  as  Abstract  Data  Types 

Coad  and  Yourdon  quote  the  Dictionary  of  Computing 
(Oxford  University  Press,  1986)  in  defining  data  abstraction 
as  "...the  principle  of  defining  a  data  type  in  terms  of  the 
operations  that  apply  to  objects  of  the  type,  with  the 
constraint  that  the  values  of  such  objects  can  be  modified  and 
observed  only  by  the  use  of  the  operations."  (Coad  and 
Yourdon,  1991,  pg.7)  Meyer  notes  that  in  describing  data 
structures  it  is  desirable  to  have  complete,  precise, 
unambiguous  descriptions  that  are  not  based  on  the  physical 


^In  C++,  there  is  an  interesting  split  in  control  over 
the  internal  interface.  (Atkinson  and  Atkinson,  1991)  A 
superclass  may  declare  class  features  to  be  private, 
protected,  or  public.  However,  it  is  the  subclass  which 
determines  how  public,  private,  and  protected  visibility 
declarations  are  inherited.  The  visibility  of  inherited 
features  can  be  declared  public,  private,  or  protected.  The 
declaration  mechanism  essentially  allows  a  subclass  to 
redeclare  inherited  public  features  as  protected  or  private, 
and  inherited  protected  features  as  private.  Inherited  private 
features  remain  private  to  the  superclass  -  subclasses  as  well 
as  users  do  not  enjoy  access  privileges  to  these  features. 
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representation  of  the  underlying  structure.  (Meyer,  1988)  An 
at'Stract  data  type  (ADT)  specifies  a  class  of  data  structures 
.  .not  by  iniplementation,  but  by  the  list  of  services 
available  on  the  data  structures,  and  the  formal  properties  of 
these  services."  (Meyer,  1988,  pp .  53-54) 

The  data  structure  and  associated  services  of  an  ADT 
conceptually  form  a  unified  whole.  The  separation  of  visible 
services  from  implementation  details,  central  to  the  notion  of 
an  abstract  data  type,  is  accomplished  by  an  interface  which 
describes  the  services  which  the  type  performs.  Consequently, 
a  user  of  a  data  type  understands  the  type  as  a  closed 
description  of  behavior,  the  successful  use  of  which  requires 
only  knowledge  of  the  interface. 

In  many  00  languages,  such  as  Eiffel  (Meyer,  1988)  and 
C++,  classes  are  equivalent  to  ADTs .  Hence,  classes,  the 
modular  units  of  interaction,  assume  a  specific  purpose:  the 
description  of  data  types.  The  interactions  between  modules 
(classes)  are  managed  through  the  type  interfaces. 
Nevertheless,  it  is  important  to  understand  that  the  principle 
function  of  classes  is  to  serve  as  templates  for  object 
instantiation  and  not  as  predicate  descriptors.  (Wegner,  1988) 
This  critical  difference  assumes  significance  when  considering 
inheritance  (described  in  the  next  section)  in  which  classes 
maintain  set/subset  relationships  to  facilitate  code  sharing. 
The  mechanisms  for  inheritance  do  not  always  meet  the  strict 


requirements  for  type/subtype  behavioral  compatibility  which 
the  class/type  equivalence  requires. 

3 .  Classes  and  Encapsulation 

Although  classes  specify  the  behavior  of  data  types, 
as  modular  software  components  they  also  embody  the 
implementation  details  of  structure  and  behavior. 
Modularization  permits  the  design  of  interfaces  which 
encapsulate  these  implementation  details,  thereby  achieving 
the  many  benefits  attributed  to  information  hiding  in  Chapter 
1.  The  class  interface  need  not  include  auxiliary  methods, 
further  increasing  encapsulation.  Hence,  the  class  interface 
not  only  describes  services  available  to  users,  but  limits  the 
ability  of  users  to  directly  know,  access,  or  modify  the 
actual  data  structure  of  a  class. 

Encapsulation  represents  a  property,  but  not  a 
responsibility  of  classes.  Programmers  must  specifically 
design  interfaces  which  segregate  implementation  from 
specification,  and  the  00  philosophy  of  the  language  must 
support  encapsulation  by  restricting  access/manipulation  of 
data  structures  to  the  designed  interface.  It  is  curious  that 
nut  every  00  language  supporting  classes  enforces 
encapsulation  as  described.  Instance  variables  in  Simula,  for 
example,  are  directly  accessible.  (Micallef,  1988)  For 
reasons  adduced  in  Chapter  I,  this  undesirable  condition 
increases  the  linkages  among  program  modules,  diluting  the 
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reliability  of  code,  and  increasing  the  difficulties  attendant 
to  maintenance. 

4 .  Categories  of  Classes 

Within  the  context  of  software  system  design,  classes 
serve  varying  purposes  depending  upon  the  requirements  of  the 
problem  and  the  nature  of  the  knowledge  being  modeled.  These 
class  roles  generally  reflect  design  decisions  about  how 
knowledge  of  data  types  should  be  distributed  in  the  evolving 
class  structure. 

a.  Abstract  Classes 

Abstract  classes  appear  at  the  higher  levels  in 
inheritance  hierarchies  (discussed  in  the  next  section) . 
Jumping  ahead,  an  abstract  class  serves  as  a  placeholder  of 
methods  and  data  common  among  the  descendant  classes  in  a 
hierarchy.  (Wu,  1991)  Hence,  an  abstract  class  serves  as  a 
repository  of  knowledge  held  in  common  by  all  of  its 
descendant  classes.  As  such,  abstract  classes  are  not 
intended  to  serve  as  templates  for  object  instantiation. 
Rather,  they  eliminate  tlie  duplication  of  knowledge  among 
related  types,  thereby  reducing  coding  complexity  and 
facilitating  testing,  debugging,  and  maintenance. 
Additionally,  abstract  classes  also  promote  the  design  of  a 
common  protocol  (interface)  among  the  related  types.  This 
figures  importantly  in  languages  emphasizing  polymorphism. 
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Jb. 


Concrete  Classes 


Concrete  classes  are  simply  classes  that  are 
intended  to  serve  as  templates  for  object  instantiation.  Note 
that  a  concrete  class  may  or  may  not  be  descended  from  an 
abstract  class.  However,  it  has  been  suggested  that  it  is 
possible  that  abstract  classes  should  not  be  descended  from 
concrete  classes,  (de  Paula  and  Nelson,  1991) 

c.  Virtual  Classes 

virtual  classes  (C4+  terminology)  contain  virtual 
methods.  Virtual  methods  are  those  methods  in  a  class  whose 
implementations  may  be  overridden  (redefined)  in  descendent 
classes.  This  allows  method  names  and  sit  .atures  to  be  shared 
(see  Section  E  on  polymorphism) .  It  should  be  noted,  however, 
that  many  00  languages  do  not  include  this  concept  -  any 
method  of  any  class  may  be  overridden  in  descendent  classes. 

d.  Pure  Virtual/Deferred  Classes 

Classes  may  exhibit  behavioral  commonalities  that 
designers  want  to  place  into  abstract  classes  without  forcing 
a  common  implementation.  Pure  virtual  classes  (C++ 
terminology)  allow  for  the  specification  of  interfaces,  part 
or  all  of  whose  methods  are  to  be  implemented  in  descendent 
classes® . 

®The  concept  of  pure  virtual  functions  should  not  be 
confused  with  the  concept  of  subclass  responsibility.  Pure 
virtual  functions  are  employed  to  ensure  such  methods  form 
part  of  the  interface  of  descendent  classes.  Subclass 
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Meyer  refines  the  concept  of  pure  virtual  classes, 
arguing  that  such  deferred  classes  (Eiffel  terminology) 
additionally  require  the  specif ication  of  logical  pre/post 
conditions  for  deferred  implementations.  (Meyer,  1988) 
Although  correct  in  principle,  it  is  difficult  to  discern  how 
this  complication  assists  design  since  a  behavior  is  elevated 
to  virtual  status  precisely  because  it  is  shared  by 
descendants,  and  should  therefore  demonstrate  the  same 
semantic  properties  in  descendent  implementations, 
d.  Parameterized  Classes 

Parameterized  classes  are  a  form  of  generic 
structures.  Such  classes  provide  methods  which  operate  on 
data  structures  whose  types  are  not  completely  defined.  An 
example  would  be  a  tree  class  for  which  the  types  of 
individual  nodes  are  undefined.  Another  example  would  be  an 
array  class  containing  elements  whose  types  are  undefined. 
Current  00  languages  do  not  offer  parameterized  classes, 
although  C++  designers  are  currently  developing  the  technique 
for  eventual  introduction.  (Budd,  1991) 


responsibility  derives  from  the  notion  of  functional 
decomposition  (see  Chapter  IV) .  Specifically,  subclass 
responsibility  involves  decisions  about  the  distribution  of 
methods  among  ancestor  and  descendent  classes  in  cases  where 
ancestor  methods  rely  on  the  )cnowledge  that  descendants  must 
implement  certain  methods. 


e.  Metaclasses 


Abstract,  concrete,  and  virtual  classes  represent 

roles  which  classes  can  assume  in  the  context  of  program 

design.  In  this  capacity,  classes  continue  to  serve  as 

patterns  for  instantiation.  Some  00  languages  (including 

Smalltalk,  for  example)  carry  through  the  object  point-of-view 

to  include  all  constructs  in  the  language  space. 

Consequently,  classes  must  be  treated  as  objects  as  well. 

This  raises  the  requirement  to  create,  initialize,  and  destroy 

classes.  To  accommodate  these  needs,  such  languages  provide 

for  metaclasses  -  classes  from  which  class  objects  are 

instantiated.  *  class  object  is  typically  the  only  instance 

of  a  metac.i ’.oS . "  (Budd,  1991,  pg.  376) 

Metaclasses  are  a  conceptual  complexity  which  are, 

mildly  expressed,  difficult  to  understand.  It  is  difficult 

to  place  an  end  to  the  recursion  implicit  in  defining 

everything  as  an  object.  For  example,  consider  this  obscure 

passage  from  Budd  describing  metaclasses  in  Smalltalk: 

The  class  Class  is  a  subclass  of  the  class  Object;  and 
thuSr  the  object  Class  points  to  the  object  Object  as  its 
superclass .  On  the  other  handr  the  object  Object  is  an 
instance  of  the  class  Class;  and  thus.  Object  points  back  to 
class.  Class  Class  is  itself  a  class,  and  thus  an  instance 
of  itself.  (Budd,  1991,  pg .  265) 

Classes  force  instances  to  exhibit  the  same 

behavior/  thus,  metaclasses  force  classes  to  exhibit  the  same 


behavior . 


Metaclasses  allow  for  class  instances  which 


specialize  the  behavior  of  other  classes.  As  an  example,  a 
class  may  need  to  override  the  constructor  for  an  object 
defined  by  another  class.  The  corresponding  metaclass  would 
allow  for  the  overriding  of  the  other  class'  constructor. 

Carried  to  its  logical  extreme,  the  idea  that  all 
constructs  in  the  programming  environment  are  objects  requires 
that  ". . .the  metaclass  must  be  considered  an  object  in  its  own 
right,  and  is  therefore  created  by  the  metametaclass,  which  is 
in  turn  created  by  the  met ainetametaclass ,  etc."  (Nelson,  1990, 
pg .  7)  Nelson  points  out  that  most  OOPLs  supporting 

metaclasses  ignore  this  problem,  or  simply  declare  metaclasses 
to  be  special  objects  provided  by  the  system.  (Nelson,  1990) 
Metaclasses  clearly  provide  a  higher  level  of 
abstraction;  nevertheless,  they  also  move  away  from  the  real- 
world  parallelism  that  00  languages  accentuate,  forming  a 
strange  dual  definition  for  classes,  and  are  perhaps  best 
relegated  to  theoretical  discussions. 

5 .  Epistemological  Issues 

a.  Objects  of  Knorrlmdge  or  Objects  of  Belief? 

An  interesting  side  issue  is  the  epistemological 
status  of  classes.  Articles  considering  class  design 
ordinarily  contain  a  seemingly  harmless  footnote  to  the  effect 
that  design  teams  should  possess  at  least  one  subject  matter 
expert  who  presumably  fully  understands  the  problem  domain 
from  both  a  theoretical  and  experiential  perspective  which 
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supersedes  the  immediate  application  problem.  At  issue  is 
whether  the  knowledge  emt>odied  by  classes  must  be  justified. 
As  an  example,  an  application  modeling  certain  kinds  of 
planetary  phenomena  may  start  from  a  Ptolomeic  or  a  Copernican 
explanation  of  behavior  and  achieve  reliable  behavioral 
results.  Yet,  only  the  Copernican  theory  is  justified  as 
knowledge.  If  one  objective  of  class  design  is  to  mimic  the 
real-world,  then  designers  should  be  required  to  justify  to 
some  degree  the  knowledge  represented  by  classes.  Too  often 
in  application  design,  belief  is  substituted  for  knowledge; 
much  to  the  detriment  of  potential  code  reuse  in  new 
applications . 

C .  INHERITANCE 

Inheritance  uniquely  distinguishes  00  languages  from  other 
programming  languages.  It  has  even  been  called  the  only 
unique  contribution  of  00  languages.  (Korson  and  McGregor, 
1990)  Within  the  family  of  OO  languages  inheritance 
mechanisms  vary  widely.  This  section  reviews  the  elasticity 
with  which  inheritance  can  be  implemented,  drawing  out  design 
implications  for  various  inheritance  strategies. 

1 .  Definition 

Inheritance  enables  the  easy  creation  of  objects  that 
are  almost  like  other  objects  with  a  few  incremental 
changes .  Inheritance  reduces  the  need  to  specify 
redundant  information  and  simplifies  updating  and 
modification^  since  information  can  be  entered  and 
changed  in  one  place.  (Stefik  and  Bobrow,  1986,  pg.41) 
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We  adopt  the  I'-iew  of  Cook  who  defines  inheritance  as 
a  composition  mechanism  that  internalizes  inherited 
attributes  by  late  (execution  time)  binding  of  self¬ 
reference  to  the  inheriting  object.  (Wegner  and 
Zdonik,  1988,  pq .  57) 

Inheritance  is  here  defined  narrowly  as  a  mechanism 
for  resource  sharing  in  hierarchies.  (Wegner,  1987, 
pg .  16  9) 

A  subclass  inherits  all  of  the  variables  and  methods 
defined  for  its  superclass  -  regardless  of  whether 
those  variables  and  methods  were  defined  locally  in 
the  superclass  or  inherited  from  some  other  class. 
(Nelson,  1991,  pg .  2) 

Inheritance  is  a  broad  _oncept  which  serves  multiple 
ends.  Hence,  inheritance  must  be  approached  from  several 
perspectives  to  gain  a  fuller  understanding  of  its  conceptual 
diversity  and  utilitarian  purposes. 

First,  inheritance  is  primarily  a  resource  sharing 
mechanism,  greatly  extending  reusability.  The  idea  that 
opportunities  for  economy  of  design  exist  can  be  drawn  from 
the  observation  that  classes  of  objects  exhibit  conceptual, 
behavioral,  or  structural  commonalities.  Specifically, 
inheritance  is  a  mechanism  which  permits  the  definition  of  one 
class  to  include  the  specification  or  implementation  of 
another  class  on  the  basis  of  these  commonalities. 

Second,  groups  of  classes  can  manifest  collective 
commonalities  which  result  in  hierarchical  relationships  among 
the  respective  class  definitions.  Inheritance  reifies  these 
relationships  into  the  actual  implementation  code.  In  the  00 
lexicon,  an  inheriting  class  is  a  subclass  of  the  superclass 


from  which  it  directly  shares  implementation  code,  and  it  is 
a  descendant  of  all  classes  to  which  a  path  (from  the  subclass 
to  higher  le  els  in  the  hierarchy)  can  be  traced.  All  the 
classes  for  which  a  given  subclass  is  a  descendant  constitute 
the  ancestors  of  that  class. 

Third,  inheritance  is  a  pliant  concept.  Depending 
upon  the  nature  of  the  commonalities  instigating  the  decision 
to  share  code,  restrictions  can  be  levied  which  shape  the 
kinds  of  code  sharing  that  are  permissible.  These 
formulations  of  the  inheritance  mechanism  are  discussed  in  the 
following  subsections.  It  should  be  noted,  however,  that 
conceptual  and  programmatic  difficultit  often  arise  from 
language  designs  which  emphasize  but  do  not  enforce  particular 
inheritance  restrictions. 

Fourth,  some  00  languages  implement  single  inheritance 
in  which  a  subclass  is  only  allowed  to  inherit  from  a  single 
superclass  while  other  00  languages  implement  multiple 
inheritance  (MI)  in  which  a  subclass  inherits  from  one  or  more 
superclasses.  MI  is  a  technique  which  powerfully  increases 
the  opportunities  for  code  reuse.  However,  MI  also  introduces 
several  ccnplicat ions ,  solutions  for  which  are  not  uniform. 
These  problems  are  discussed  in  the  MI  subsection  below,  and 
further  examined  in  Chapter  V. 
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Finally,  inheritance  mechanisms  can  undermine  other 
desirable  00  language  features.  Chapter  V  considers  potential 
conflicts  engendered  by  inheritance. 

2 .  Inheritance  Elasticity 

As  previously  stated,  classes  provide  instance 
variables,  class  variables,  and  methods,  and  they  serve  as 
templates  for  object  instantiation.  Inheritance  entails 
decisions  about  the  manner  in  which  existing  classes  can  be 
modified  to  form  new  templates.  (Wegner  and  Zdonik,  1988)  To 
facilitate  discussion,  inheritance  can  be  described  as  a 
. .particular  kind  of  incremental  modification  mechanism  that 
transforms  a  parent  entity  P  with  a  modifier  M  into  a  result 
entity  R  =  P+M. "  (Wegner  and  Zdonik,  1988,  pg.  55)  P  and  M 
consist  of  sets  of  attributes  (variables  and  methods)  which 
may  or  may  not  be  disjoint.  Disjoint  attribute  sets  do  not 
present  any  particular  problem.  Problems  arise  in  determining 
the  manner  in  which  overlapping  attributes  will  be  treated. 

It  bears  emphasizing  that  inheritance  is  a 
subclassing,  not  a  subtyping®,  mechanism.  Inheritance 

realizes  different  kinds  of  templates  depending  on  the 
constraints  applied  to  the  sharing  of  attributes. 

’Subclassing  is  a  set  theoretical  concept  in  which  the 
members  (variables  and  methods)  of  the  subclass  include  all 
the  members  of  the  superclass.  Subtyping  is  a  behavioral 
concept  in  which  any  object  of  a  subtype  can  be  substituted 
for  an  object  or  the  supertype  and  still  respond  to  any 
service  requests  with  the  desired  behavior. 


a.  Logical  Possibilities 


It  is  useful  to  classify  the  various  logical 
possibilities  for  resource  sharing  under  inheritance  as  either 
interface  sharing  or  implementation  sharing.  An  00  language 
may  allow  either  or  both  of  these  forms  of  sharing,  refining 
the  individual  categories  through  constraints. 

Interface  sharing  entails  the  reuse  of  a  class' 
interface,  but  not  the  actual  implementation  of  the  interface. 
Variable  names  and  types  are  shared.  Additionally,  method 
names  and  parameters^''  are  shared.  Interface  sharing  can 
assume  the  following  forms“: 

^Variable  names  and  types  are  shared. 

o Method  names  and  parameters  are  shared. 

o Variable  and  method  names,  types,  and 
parameters  are  shared. 

Implementation  sharing  entails  the  sharing  of 
method  bodies.  Such  sharing  offers  the  greatest  opportunities 


^“Parameter  sharing  includes  the  names,  number,  and  types 
of  parameters  as  well  as  parameter  qualifier  distinctions  (in 
versus  out) . 

^^Note  that  signature  sharing  is  purely  a  syntactic 
matter.  (Wegner  and  Zdonik,  1988)  Specification  sharing 
provides  for  sharing  descriptions  of  the  effects  of  methods. 
(Krakowiak  et  al,  1990)  Hence,  specification  sharing  allows 
for  semantic  associations.  "In  the  current  state  of  the  art, 
the  specification  is  only  a  comment  and  is  not  subject  to  any 
formal  processing.  However,  it  is  considered  an  integral  part 
of  the  type  definition."  (Krakowiak  et  al,  1990,  pg.  13) 
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for  code  reuse.  Implement  at.  ion  sharing  can  assume  the 
following  forms: 

o Implementation  code  is  directly  shared. 

o Implement ation  code  is  extended. 

o Implementation  code  is  overridden. 

oPortions  of  implementation  code  are 
excluded . 

Logically  separate  from  inheritance,  but  an 
elemental  consequence  of  the  principles  guiding  the 
construction  of  class  hierarchies,  is  the  capacity  to  include 
new  variables  and  methods  in  subclasses.  Hence,  inheritance 
takes  shape  as  a  cross-product  of  the  listed  options  and 
extendibility .  In  most  00  languages,  inheritance  combines  both 
interface  and  implementation  sharing.  Virtual/deferred 
attributes  allow  for  the  inheritance  of  interfaces  alone. 

The  following  subsections  draw  upon  Wegner  and 
Zdonik's  analysis  of  incremental  modification  in  the  context 
of  inheritance.  (Wegner  and  Zdonik,  1988)  The  authors  assert 
that  every  class  is  a  type  describing  a  template.  Their 
analysis  is  concerned  with  isolating  the  restrictions  on 
inheritance  (template  modifications)  that  flow  from  different 
methods  of  specifying  the  behavior  of  types.  The  principle 
concern  is  that  subtype  behavior  be  compatible  with  supertype 
behavior.  Different  notions  of  compatibility  emanate  from  the 
differing  specification  methods.  There  is  a  strong 
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predisposition  that  a  class  hierarchy  should  be  structured  to 
account  for  substitution  possibilities  (of  subtypes  for 
supertypes)  .  However,  Wegner  and  Zdonik  conclude  that  a 
strict  interpretation  of  the  subtype  idea  is  overly  narrow, 
intruding  upon  the  flexibility  which  the  subclassing  mechanism 
permits.  This  leads  inexorably  to  the  conclusion  that  an  00 
language  ought  to  provide  weaker  forms  of  typing/subtyping, 
thereby  arming  the  programmer  with  the  greatest  leverage  for 
designing  class  hierarchies.  A  supporting  reason  for  such 
hierarchies  is  that  objects  in  the  real  world  do  not  often 
manifest  relationships  as  conceived  by  strict  subtyping,  but 
exhibit  a  much  richer  set  of  similarities  that  class 
hierarchies  should  emulate. 

a.  Bahavior  Compatibility 

Behavioral  compatibility  "...may  be  specified  by 
algebras  with  a  signature  and  a  semantics."  (Wegner  and 
Zdonik,  1988,  pg .  62)  Hence,  if  classes  are  to  be  modeled 
such  that  the  resulting  class  hierarchy  doubles  as  a 
behaviorally  compatible  type  hierarchy,  then  inheritance 
should  be  constrained  to  maintain  a  complete  supertype/subtype 
relationship  between  superclass  and  subclass^^.  This  entails 
some  notion  about  the  requirements  for  complete  behavioral 
compatibility  in  these  relationships.  Specifically,  the 

^^The  critical  notion  is  that  the  semantics  of  behavior 
must  be  compatible. 
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concept  of  substitutability  must  be  defined  for  subtypes. 
Wegner  and  Zdonik  define  the  principle  of  substitutability  as 
follows : 

An  instance  of  a  subtype  can  always  be  used  in  any  context 
in  which  an  instance  of  a  supertype  was  expected .  (Wegner 
and  Zdonik,  1988,  pg .  65) 

They  then  proceed  to  note  that  the  only  form  of  compatibility 
in  which  this  notion  of  substitutability  is  preserved  is  that 
kind  of  inheritance  in  which  subclasses  are  restricted  to 
adding  new  variables  or  methods^\  and  do  not  alter  the 
semantics  (modify  variable,  argument,  or  result  domains)  of 
superclass  features.  (Wegner  and  Zdonik,  1988)  The  sort  of 
compatibility  envisioned  is  therefore  both  syntactic  and 
semantic.  It  is  doubtful  that  a  practical  compiler  could  be 
designed  to  determine  complete  behavioral  compatibility, 
especially  as  such  compatibility  cannot  be  specified  in 
current  programming  languages. 

Clearly,  complete  subtype  compatibility  is  a 
highly  restrictive  notion  and  not  enforced  by  current  00 
languages.  In  the  analysis  of  class  relationships, 
distinctions  are  often  drawn  between  inheritance  and  type 
hierarchies.  (Palsberg  and  Schwartzbach,  1990)  Though  many 
OOPLs  identify  subclassing  with  subtyping,  it  was  previously 
noted  that  the  two  concepts  are  not  the  same.  Consequently, 

^•’Wegner  and  Zdonik  use  the  term  "horizontal  extension." 
(Wegner  and  Zdonik,  1988,  pg.  64). 


it  is  possible  to  design  type  hierarchies  which  do  not 
parallel  the  class  hierarchy.  Based  upon  this  distinction,  it 
is  of  interest  to  note  that  so  long  as  data  structures  are 
encapsulated,  objects  of  a  class  (as  a  data  type)  whose 
interface  syntactically  parallels  the  interface  of  other 
classes  should  be  substitutable  for  objects  of  these  other 
classes  independent  of  inheritance  relationships.  This  notion 
of  subtype  compatibility  appears  feasible.  However,  languages 
such  as  C++  and  Eiffel  restrict  subtyping  to  inheritance 
relationships  to  simplify  the  complexity  of  algorithms 
performing  compile  time  type  checking,  therefore  improving 
performance . 

b.  Signature  Compatibility 

Signature  compatibility  (syntactic  compatibility 
as  described  above)  drops  the  requirement  for  behavioral 
compatibility.  In  particular,  the  domains  of  inherited 
attributes  may  be  modified.  The  term  "vertical  modification" 
describes  such  domain  changes.  (Wegner  and  Zdonik,  1988,  pg. 
64)  A  signature  compatible  subtype  (vertically  modified) 
cannot  be  assigned  to  a  supertype.  A  weaker  form  of 
substitutability  is  therefore  offered  in  which  an  instance  of 
a  subtype  can  be  used  in  read-only  mode  in  any  context  a 
supertype  is  expected.  (Wegner  and  Zdonik,  1988)  The  authors 
describe  the  relationships  between  entities  in  completely 
behavioral  compatibility  as  c'^nsistent  with  '  is  a' 
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hierarchies.  However,  as  LaFonde  and  Pugh  point  out,  'is  a' 
is  not  the  same  as  subtype,  but  rather  is  a  specialization 
relationship.  (LaLonde  and  Pugh,  1991)  Such  relationships 
better  coincide  with  signature  compatibility. 

c.  Name  Compatibility 

Name  compatibility  "...requires  only  the  name  and 
not  the  signature  of  the  parent  type  to  be  preserved  in  the 
result."  (Wegner  and  Zdonik,  1988,  pg .  66)  This  is  a  simple 
and  flexible  form  of  incremental  modification  employed  by  many 
00  languages  (such  as  Smalltalk) .  Name  compatible 
modification  entails  searching  the  inheritance  path  (beginning 
with  the  result  class)  for  the  first  occurrence  of  a  name. 
Some  00  languages  modify  the  search  algorithm  by  including 
syntax  which  permits  definitions  to  be  directly  selected  from 
ancestor  classes  (such  as  double  dot  notation  in  C++  or 
'super'  in  Smalltalk). 

d.  Selective  Inheritance 

Selective  inheritance*^  introduces  the  useful 
option  of  deleting  inherited  attributes.  Selective 
inheritance,  however,  disrupts  subtyping  relationships  should 
they  exist.  To  facilitate  reasoning  about  classes  whose 
behavior  is  similar,  but  for  which  selective  inheritance  is 
employed,  Wegner  and  Zdonik  introduce  the  term  "liketype." 

'^Wegner  and  Zdonik  use  the  term  "cancellation."  (Wegner 
and  Zdonik,  1988,  pg.  67) 


(Wegner  and  Zdonik,  1988,  pg .  73)  Liketypes  logically  include 
the  other  incremental  modification  mechanisms.  Consequently, 
the  authors  recommend  using  like  relationships  to  structure 
inheritance  hierarchies,  applying  constraints  to  the  like 
relationship  as  needed  to  achieve  desired  compatibility 
relationships  between  superclasses  and  subclasses. 

Cancellation  modification  mechanisms  alone  provide 
for  all  the  logical  inheritance  possibilities.  It  is 
interesting  to  observe  that  no  OO  languages  that  we  know  of 
implement  cancellation  mechanisms  directly.  The  difficulties 
in  managing  intraclass  linkages  among  attributes  when 
cancellation  is  employed  probably  explains  the  absence  of  such 
cancellation  mechanisms  (as  well  as  the  adherence  to  some  sort 
of  strong  typing  philosophy) . 

3.  Specialization 

Several  strategies  can  be  employed  to  design  class 
hierarchies.  The  possibilities  include  type,  specialization, 
and  like  hierarchies.  Additionally,  classes  may  exhibit  no 
abstract  commonalties  whatsoever  other  than  code  sharing  or 
interface  sharing.  In  the  literature,  however,  specialization 
is  typically  described  as  the  primary  principle  for  hierarchy 
design.  Yet,  a  precise  formula  for  building  such  hierarchies 
has  not  found  general  acceptance.  As  the  discussion  in  the 
previous  subsection  suggests,  this  probably  reflects  a  desire 
on  the  part  of  designers  to  maintain  maximum  flexibility. 
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Specialization  hierarchies  are  also  called  'is  a' 
hierarchies  (e.g.,  an  eagJe  'is_a'  bird).  Booch  describes 
'is_a'  hierarchies  as  consisting  of  "...superclasses 
representing  generalized  abstractions,  and  subclasses 
representing  specializations  in  which  fields  and  methods  from 
the  superclass  are  added,  modified,  or  even  hidden."  (Booch, 
1991,  pg.  56) 

What  qualifies  as  specialized  behavior?  What 
correspondence  should  there  be  between  the  mechanisms  which 
implement  inheritance  and  the  abstractions  which  relate 
classes  in  a  specialization  hierarchy?  A  return  to 
epistemological  issues  is  evident.  It  appears  reasonable  that 
a  standardized  notion  of  specialization,  based  upon  some  sort 
of  philosophical  foundation,  is  required  to  introduce 
continuity  to  hierarchy  construction  and  to  facilitate  the 
construction  of  compatible  hierarchies  (which,  afterall,  form 
the  00  libraries  central  to  code  reusability) . 

Ultimately,  the  range  of  implementable  hierarchies 
entails  decisions  about  the  distribution  of  responsibilities 
between  programmers  and  language  designers.  Restrictive 
languages  (basically  strongly  typed  languages)  ensure  that 
programs  are  compiled  in  which  undefined  operations  on  objects 
are  caught  by  the  compiler.  As  flexibility  increases,  the 
programmer  must  ensure  that  undefined  operations  on  objects  do 
not  happen  (i.e.,  explicitly  indicate  to  the  system  what  class 


relationships  prevail  so  that  the  compiler  or  run-time 
environment  can  enforce  programmer  intentions) . 

4 .  Multiple  Inheritance 

A  subclass  may  inherit  from  several  superclasses. 
Budd  agrees  that  'is_a'  relationships  should  guide  the 
construction  of  MI  hierarchies  (directed  acyclic  lattices) , 
noting,  however,  that  the  resulting  subclass  should  be  viewed 
as  a  specialized  "...combination  or  collection  of  several 
different  components."  (Budd,  1991,  pg .  173)  The  idea  of 
suk>class  as  combination  produces  both  the  richness  and 
difficulties  that  frame  discussions  about  MI.  In  particular, 
what  kinds  of  combinations  should  be  permissible,  and  what 
status  should  be  accorded  subclass  entities?  Designers  have 
not  arrived  at  a  consensus  on  these  questions,  which  may 
explain  why  very  few  00  languages  actually  implement  MI. 

MI  also  introduces  new  problems.  Prominent  problems 
include  name  conflicts  and  inheritance  from  a  common  ancestor. 
Name  conflict  resolution  strategies  must  be  developed. 
Knudsen  provides  a  useful  framework  for  analyzing  such 
conflicts,  distinguishing  horizontal^'  from  vertical^®  name 
collision.  (Knudsen,  1988)  Such  conflicts  can  be 


^'Attributes  with  the  same  name  are  inherited  from 
multiple  superclasses. 

'^Subclass  possesses  attributes  with  the  same  name  as 
attributes  in  one  or  more  superclasses. 
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characterized  in  three  ways  (Knudsen,  1988)  :  (1)  the  same 
phenomena  are  defined;  (2)  casually  related  phenomena  are 
defined;  and,  (3)  unique  phenomena  are  defined  in  which  no 
collisions  are  permissible.  The  first  method  is  handled  by 
polymorphic  techniques,  the  second  by  resolution  operators^^ 
(such  as  double  dot  notation  in  C++) ,  and  the  last  will  give 
rise  to  compile-time  errors. 

inheritance  from  a  common  ances+or  involves 
inheritance  of  attributes  from  superclasses  w’hose  inheritance 
paths  converge  at  a  common  ancestor.  At  issue  is  the 
duplication  of  attributes.  Should  one  or  all  attributes  be 
inherited?  If  all  are  inherited,  how  are  they  to  be 
distinguished?  Solutions  to  this  problem  are  discussed  in 
Chapter  V. 

5 .  Delegation 

Some  00  languages  approach  reusability  from  a 
different  philosophic  perspective.  In  lieu  of  classes  and 
inheritance  to  facilitate  sharing  the  implementation  of 
template  abstractions,  these  languages  "...directly  use 
objects  as  prototypes  from  which  the  default  behavior  for 
concepts  can  be  reused."  (Lieberman,  1986,  pg.  214)  An  object 
can  delegate  its  attributes  to  one  or  more  prototypes.  Hence, 
an  object  receiving  a  message  may  defer  to  another  object  to 

''Renaming  or  redefining  subclass  attributes  is  another 
solution.  (Budd,  1991,  pg.  174) 


formulate  the  response.  Delegation  is  the  mechanism  for 
implementing  this  in  these  00  languages.  (Lieberman,  198G) 

Proponents  of  delegation  contend  that  it  is  more 
flexible  and  general  than  inheritance.  Lieberman  argues  that 
inheritance  fixes  communication  patterns  between  objects  at 
instance  creation  time  whereas  delegation  allows  any  object  to 
serve  as  a  prototype  at  any  time.  (Lieberman,  1986)  However, 
delegation  also  carries  the  burden  that  objects  are  dependent 
on  one  another.  Stein  asserts  that  any  changes  to  attributes. 


or  their 

values , 

will 

affect  both  the 

object  and  the 

prototype . 

(Stein, 

1987) 

More  importantly. 

Stein  presents  a 

formal  model  which 

draws 

out  the  essent  al 

implications  of 

classes  qua  templates:  template  instances  are  guaranteed  to 
possess  the  same  structural  properties,  but  value 
independence.  (Stein,  1987)  The  very  flexibility  of 
delegation  eliminates  any  sort  of  structural  guarantees  and 
value  independence  for  objects  in  an  object  hierarchy. 

Delegation  also  raises  epistemological  questions. 
Given  the  run-time  maneuverability  of  an  object  to  delegate  to 
other  objects,  it  is  perplexing  as  to  what  sort  of  knowledge 
is  actually  being  modeled.  Objects  in  a  delegation  hierarchy 
resemble  amorphous  entities  amenable  to  the  demands  of  the 
moment,  but  lacking  assured  structural  or  behavioral 
continuity . 
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In  1987,  a  compromise  of  sorts  to  the  inheritance 
versus  delegation  'controversy'  was  decided  b'  ^eaty  of 
Orlando.  (00PL5A  Addendum  to  the  Proceedings,  1987) 
Provisions  of  the  treaty  accepted  that  the  sharing 
mechanism  could  occur  along  three  independent  dimensions:  (1) 
static  or  dynamic’®;  (2)  implicit  or  explicit'”;  and,  (3)  per 
object  or  per  group*'  .  The  pC'Sition  adopted  in  the  treaty  was 
"...tliat  different  programming  situations  call  for  different 
conibinat  ions  of  these  features."  (OOFLSA  Addendum  to  the 
Proceedings,  1987,  pg .  43)  More  than  likely,  the  marketplace 
will  be  the  final  arbiter  between  the  two  approaches. 

D.  COMPOSITION 

Another  prominent  relationship  among  real-world  entities 
is  composition  (also  called  aggregation);  complex  objects  can 
be  conceived  as  consisting  (i.e.,  being  composed  of)  of 
aggregates  of  other  objects.  Hence,  an  object  is  'part  of' 
another  object  (e.g.,  a  wheel  is  'part_of'  a  car) .  Stefik  and 
Bobrow  consider  a  composite  object  to  be  "...a  group  of 


^®The  time  that  a  system  requires  sharing  patterns  to  be 
fixed  (compile  or  runtime) .  (OOPSLA  Addendum  to  the 
Proceedings,  1988) 

'^Sharing  patterns  can  be  declared  by  programmers 
(explicit)  or  automatically  (implicit) .  (OOPSLA  Addendum  to 
the  Proceedings,  1987) 

‘“sharing  can  be  specified  for  an  object  at  a  time  (per 
object)  or  for  a  group  of  objects  at  a  time  (per  group)  . 
(OOPSLA  Addendum  to  the  Proceedings,  1987) 
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interconnected  objects  that  are  instantiated  together,  a 
recursive  extension  of  the  notion  of  object."  (Stefik  and 
Bobrow,  1986,  pg .  51)  Several  ideas  can  be  drawn  from  this 
conception  of  composite  objects. 

First,  composition  is  another  mechanism  for  reusability. 
The  class  template  for  a  group  of  objects  may  include  the 
previously  defined  templates  for  other  classes  of  objects  - 
redefinition  is  not  necessary.  Booch  notes  that  such 
composition  relationships  can  be  implemented  through  two 
mechanisms  (Booch,  1991) :  (1)  declaration  of  class  instance 
variables  as  user  defined  types;  and,  (2)  declaration  of 
formal  parameters  for  class  methods  as  user  defined  types  (as 
a  parameter  to  the  class  interface) . 

Second,  the  interconnectedness  of  objects  in  composition 
relationships  occurs  through  the  respective  object  interfaces. 
This  serves  to  preserve  encapsulation.  Nevertheless,  the 
interconnectedness  also  establishes  a  coupling  between 
respective  classes.  The  implications  of  this  coupling  will  be 
examined  in  Chapter  V. 

Third,  composition  should  not  be  confused  with  inheritance 
(either  single  or  multiple) .  In  particular.  Halbert  and 
O'Brien  point  out  that  a  "...subclass  inherits  from  a 
superclass  only  once  while  aggregation  allows  more  than  one 
instance  of  a  particular  object  type."  (Halbert  and  O'Brien, 
1987,  pg.  76) 
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Fourth,  the  notion  of  composition  as  a  recursive 
definition  highlights  the  fact  that  members  of  a  composite 
object  may  themselves  also  be  composite  objects. 
Consequently,  any  level  of  nested  complexity  is  possible. 

Finally,  it  is  interesting  to  ask  how  composite  objects 
differ  from  collections  of  objects  cooperating  collectively  to 
achieve  a  systematic  pattern  of  behavior.  The  answer  is  that 
the  differences  are  mostly  in  the  respective  degrees  of 
abstraction  and  complexity.  Composite  objects  can  themselves 
be  viewed  as  systems  (e.g.,  a  car)  .  However,  the  level  of 
complexity  and  abstractness  for  systems  such  as  a  factory  is 
elevated  enough  that  it  should  not  be  localized  into  a  single 
object .  These  application  specific  decisions  reflect  design 
considerations  about  the  distribution  of  knowledge,  and 
visibility  of  objects. 

E.  POLYMORPHISM 

Polymorphism  is  one  of  the  more  abstruse  concepts  in  the 
00  literature.  Consequently,  a  variety  of  approaches  are 
taken  toward  delimiting  its  meaning.  That  inheritance, 
specialization,  message  passing,  and  polymorphism  all  interact 
to  achieve  reusability  and  extendibility  further  complicates 
isolating  the  content  and  effects  of  polymorphism. 

Budd  observes  that  definitions  of  polymorphism  often 
overlap  other  concepts  such  as  overloading.  (Budd, 1991)  This 
section  reviews  several  polymorphic  mechanisms  without  regard 
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to  delineating  the  boundaries  with  overlapping  concepts.  The 
intent  is  to  establish  the  manner  in  which  00  languages 
implement  polymorphism. 

1 .  Abstract  Qualities 

In  programming  languages,  "a  polymorphic  object  is  an 
entity,  such  as  a  variable  or  function  argument,  that  is 
permitted  to  hold  values  of  differing  types  during  the  course 
of  execution."  (Budd,  1991,  pg.  185)  Most  OOPLs  provide  an 
efficient  message  passing  construct  that  enables  receivers  of 
messages  to  change.  (Ingalls,  1986)  Finally,  Meyer  states 
that  in  strongly  typed  environments  (such  as  C++,  Eiffel, 
etc.),  the  changing  among  types  or  message  receivers  is 
constrained  by  inheritance.  (Meyer,  1988) 

What  emerges  is  the  notion  that  polymorphism  describes 
a  group  of  mechanisms  that  permit  programming  constructs 
(i.e.,  method  names,  method  arguments,  and  objects)  to  shift 
definitions  in  the  course  of  program  execution.  Individual 
languages  must  be  studied  to  understand  how  the  shifting  is 
accomplished.  For  example,  some  languages  distinguish  the 
static,  declared  class  of  an  object  from  the  dynamic  class  of 
its  value.  (Meyer,  1988)  Polymorphism  is  managed  in  these 
languages  through  manipulations  of  references  and  pointers. 
Other  languages  manage  polymorphism  by  binding  values  to 
objects  at  run-time  only. 
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2  .  Polymorphic  Naunes 

This  form  of  polymorphism  occurs  when  the  same  message 
can  be  sent  to  different  objects.  It  is  commonly  associated 
with  the  overloading  of  function  names.  Hence,  several 
(possibly  unrelated)  classes  may  have  a  method  with  the  same 
name.  A  standard  example  is  the  method  print^\ 

3  .  Polymorphic  Names  and  Argriments 

Another  variant  of  overloading  occurs  when  methods 
with  the  same  name  have  different  argument  cardinality  or 
different  argument  types'*.  The  methods  are  all  grouped  within 
a  single  class.  A  standard  example  is  the  constructor 
function  in  C++  classes. 


^^For  example,  several  classes  may  have  a  method  named 
print  which  has  no  arguments.  Individual  objects  from  the 
different  classes,  when  receiving  the  print  request, 
understand  that  the  local  implementation  of  the  print  method 
is  to  be  used.  Polymorphism,  used  in  this  manner,  avoids  the 
undesirable  construction  of  large  case  statements  which  match 
methods  to  objects.  Such  large  case  statements  also  assume  too 
much  knowledge  on  the  part  of  one  object  about  other  objects. 


**Micallef  describes  this  as  "multiple  polymorphism. " 
(Micallef,  1988,  pg .  32)  in  which  there  is  more  than  one 
polymorphic  variable.  She  distinguishes  this  from  simple 
polymorphism  in  which  the  "operation  invoked  is  dependent  on 
the  type  of  only  one  argument,  the  receiver  of  the  object." 
(Micallef,  1988,  pg .  32)  The  idea  is  that  the  same  method 
name  may  be  employed  by  different  classes  (simple 
polymorphism)  ,  or  by  more  than  one  method  within  a  single 
class  (multiple  polymorphism) . 
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4 .  Varia 


The  forms  of  polymorphism  listed  above  represent  the 
basic  cases  found  in  must  00  languages.  Budd  additionally 
includes  overriding,  virtual,  deferred,  and  parametric 
techniques^'  among  his  list  of  polymorphic  mechanisms.  (Budd, 
1991) 

F.  CONCLUSIONS 

The  00  paradigm  has  evolved  since  the  introduction  of  the 
first  00  language,  CEMBALO  (Meyer,  1988),  in  1968  to  encompass 
objects,  classes,  and  inheritance.  It  is  inheritance  (or 
delegation)  which  uniquely  distinguishes  00  languages  from 
other  programming  languages.  Languages  w  j.ch  include  objects 
and  classes,  but  not  inheritance/delegation  are  called  object- 
based  languages  (for  example,  Ada) .  'urrently,  the  greatest 
impediment  to  the  commercial  ascendancy  of  the  00  paradigm  as 
the  methodology  of  choice  for  language  design  is  the  lack  of 
conceptual  standardization. 


^’Overriding  occurs  when  a  subclass  redefines  the  body  of 
an  ancestor  method.  The  other  techniques  are  discussed  in  the 
section  describing  classes. 
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Ill .  00  DEVELOPMENT 


A.  SOFTWARE  ENGINEERING  METHODOLOGIES 

Software  engineering  is  the  application  of  science  and 
mathematics  to  the  problem  of  making  computers  useful  to 
people  via  software .  (Berzins  and  Luqi,  1991,  pg.  1) 

Software  engineering  finds  its  genesis  in  the  perception 

during  the  1960's  that  software  production  was  a  disorganized 

process,  the  vagaries  of  which  often  resulted  in  avoidable 

increases  in  the  total  cost  of  software  over  the  lifetime  of 

a  product^.  (Schach,  1990)  Computer  scientists  set  about  on 

a  scientific  search  for  principles  which  would  objectify  the 

process  of  software  development.  As  the  discipline  evolved, 

many  of  the  software  properties  discussed  in  Chapter  I  were 

established.  The  search  for  development  methods  which 

accentuated  these  properties  has  naturally  been  influenced  by 

the  underlying  philosophy  (or  paradigm)  adopted  for 

understanding  application  domains. 

Currently,  many  computer  scientists  are  investigating 

strategies  for  managing  a  transition  from  non-00  based 


^The  manifold  problems  which  produced  huge  increases  in 
the  total  cost  of  software  during  the  1960's  have  collectively 
been  termed  the  "software  crisis."  (Schach,  1990,  pg.  5) 
Particular  emphasis  has  been  directed  toward  the  excessive 
costs  associated  with  software  maintenance.  (Booch,  1987) 
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aevelopment  methodologies  to  00  based  methodologies^.  A  wide 
variety  of  opinion  exists  as  to  the  preferred  course  to 
follow.  This  chapter  reviews  software  development  aspects 
programmers  should  consider  in  assessing  the  relative  merits 
of  various  strategies,  considers  several  approaches  to  00 
development,  and  advances  developm.ent  recommendations. 

1 .  Lif«cycle  Organization 

In  object-oriented  analysis,  we  seek  to  model  the 
world  by  identifying  the  classes  and  objects  that  form 
the  vocabulary  of  the  problem  domain,  and  in  object- 
oriented  design,  we  invent  the  abstractions  and 
mechanisms  that  provide  the  behavior  that  this 
model  requires .  (Booch,  1991,  pg .  141) 

The  advent  of  software  engineerin  produced  a  mindset 

which  focused  on  decomposing  complex  ideas  and  processes  into 

simpler  ones.  Decomposition  of  the  development  process  itself 

produced  models  of  varying  constitution,  but  models  usually 

included  the  following  stages^:  requirements  analysis, 

specification,  design,  implementation,  maintenance,  and 

retirement.  (Schach,  1990)  Structured  techniques  based  upon 


^For  example,  Booch  1991,  Coad  1991,  Li  1991,  Pun  1991, 
Odell  1991,  and  Arnold  1991  all  discuss  new  approaches  to 
software  development  based  upon  the  00  paradigm.  Debate 
focuses  on  the  most  efficient  manner  in  which  to  shift  from 
current  methodologies  based  upon  structured  techniques 
(analysis,  design,  and  implementation  guided  by  functional 
decomposition  of  the  application  domain)  to  00  techniques. 
Advocacy  ranges  from  evolutionary  to  revolutionary  strategies. 
(Li,  1991) 

^These  stages  are  collectively  referred  to  as  the 
"software  lifecycle."  (Schach,  1990,  pg.  43) 
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functional  decomposition  were  used  to  further  simplify  each 
stage  in  the  software  lifecycle. 

The  00  development  process  is  generally  structured  in 
terms  of  OOA,  OOD,  and  OOP.  OOA  is  concerned  with  defining 
concepts  in  the  problem  domain.  It  is  through  OOA  that 
knowledge  about  the  real-world  is  captured^.  OOD  extends  the 
results  of  OOA,  uncovering  entities  missed  by  OOA,  others  that 
meet  user  requirements,  and  still  other  entities  that  are 
needed  to  consolidate  an  application  into  a  serviceable  tool 
(for  example,  user  interfaces  and  task  managers)  .  OOP 
involves  the  actual  implementation  of  the  results  of  OOD. 
There  is  no  rigid  formula  for  conducting  these  stages;  various 
temporal  schemes  can  be  utilized,  the  net  results  of  which  are 
iterative  development  processes  best  described  as  "...round- 
trip  gestalt."  (Booch,  1991,  pg.  188) 

Debate  exists  over  "...whether  to  replace  structured 
techniques  and  functional  decomposition  by  object-oriented 
techniques,  or  whether  to  look  for  a  pragmatic  solution  in 
which  existing  investments  are  retained  to  a  significant 
degree  and  tools  and  methods  modified  to  encompass  the  object- 
oriented  paradigm"  .  "  (Henderson-Sellers  and  Constantine,  1991, 

*Hence,  as  suggested  in  Chapter  II,  OOA  requires  subject 
matter  expertise. 

"Henderson-Sellers  and  Constantine  note  that  the 
OOA/OOD/OOP  breakdown  can  be  handled  in  any  of  several  ways. 
That  is,  though  the  objective  of  each  stage  is  to  produce  00 
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pg .  18)  Consequently,  strategies  for  00  development  entail 
decisions  about  which  techniques  to  apply  during  each 
lifecycle  stage.  Ultimately,  where  an  analyst  falls  on  this 
issue  largely  depends  upon  his  philosophical  predisposition  to 
adhere  to  purely  00  concepts  and  technicjues,  and  upon  the 
availability  of  00  development  environments*.  Currently,  the 
preponderance  of  development  strategies  employ  modified 
structured  technicfues^ . 

It  should  be  pointed  out  that  OOA/OOD  concepts  and 
techniques  are  serviceable  tools  for  development  leading  to 
implementation  in  non-OOPLs.  The  00  approach  to  knowledge 
representation  (objects  and  their  relationships)  facilitates 
problem  understanding  in  a  manner  that  is  transferable  to  non¬ 


results,  the  techniofues  adopted  at  a  given  stage  may  be  purely 
00,  or  they  may  be  structured  techniques  modified  to  produce 
00  usable  results.  (Henderson-Sellers ,  1991)  The  critical 
question  is  whether  structured  techniques  can  in  fact  be 
facilely  modified  to  accommodate  00  thinking.  The  answer  to 
this  question  entails  both  conceptual  and  economic 
considerations:  (1)  can  techniques  based  upon  functional 
decomposition  be  used  to  uncover  fundamentally  different 
entities  and  relationships  (i.e.,  objects,  classes,  and 
inheritance) ;  and,  (2)  can  structured  techniques,  if  used,  be 
employed  efficiently  with  a  minimum  of  modification. 

*It  is  one  thing  to  argue  for  purely  00  techniques,  quite 
another  to  actually  provide  such  methods  and  tools. 

^Data  flow  diagrams  (DFD) ,  entity  relationship  diagrams 
(ER)  ,  state  transition  diagrams,  or  event-response  diagrams 
are  incorporated  into  many  00  development  approaches.  For 
example,  Booch  1991,  Rumbaugh  1991,  and  Li  1991  all  include 
some  of  these  techniques  as  part  of  their  development 
methodology . 
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00  programming.  Specifically,  OOA/OOD  can  serve  to  structure 
high-level  abstractions  which  can  then  be  tailored  to  suit  the 
requirements  of  individual  programming  languages. 

2 .  Conceptual  Organization 

When  investigating  proposed  approaches,  it  is 
important  to  consider  the  primary  conceptual  blocks  (or 
models)  used  to  abstract  a  problem:  does  an  approach  directly 
compose  analysis  in  terms  of  objects,  classes,  and 
hierarchies?  Many  structured  techniques  do  not  abstract 
problem  entities  in  this  manner.  In  particular,  structured 
techniques  map  real-world  entities  to  functions  and  data,  (de 
Champeaux  et  al,  1990,  pg.  135  -  139)  Heuristics  must  then  be 
applied  to  transition  to  an  00  conceptualization. 

Two  other  difficult  development  problems  must  also  be 
investigated.  First,  00  development  requires  methods  for 
recognizing  and  structuring  systems.  For  present  purposes, 
systems  analysis  in  the  00  framework  is  narrowly  conceived  of 
as  a  process  which  determines  groupings  of  objects  that 
accomplish  some  pattern  (or  subpattern)  of  collective 
behavior.  At  issue  is  how  analysts  go  about  identifying  and 
relating  these  abstractions.  The  problem  is  a  subtle  one 
since  the  system  behavior,  exercised  as  collections  of 
cooperating  objects,  is  diffused  throughout  the  class 
hierarchies.  Analysts  are  therefore  confronted  with  a  twofold 
problem:  (1)  determine  the  functional  responsibilities  of  a 
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system  and  its  constituent  subsystems/  and,  (2)  determine  the 
best  manner  for  distributing  these  behaviors  among  the 
classes.  Few  proposed  00  development  approaches  adequately 
handle  this  analytical  problem;  a  problem,  it  should  be  noted, 
that  structured  technicpaes  manage  quite  well. 

Second,  reusability  inevitably  covers  the  entire 
development  spectrum.  Viewed  from  this  persp^ective,  it  is 
appropriate  to  question  how  development  should  be  conducted 
given  that  analyses,  designs,  and  programs  can  be  reused  as 
elements  in  future  development  efforts.  Specifically,  OOA, 
OOD,  and  OOP  no  longer  focus  solely  n  the  present  project, 
but  potentially  supply  source  material  for  future  projects. 
What  concepts  should  guide  development  under  these 
circumstances?  Are  some  designs  more  reusable  than  others? 
Can  potential  reusability  be  measured?  Clearly,  reusability 
requires  further  research. 

3 .  Notational  Organization 

Closely  allied  to  conceptual  organization  is  the 
notational  scheme  adopted.  Are  the  transitions  between 
development  phases  enhanced  or  impeded  by  notational  tools? 
Does  the  notation  employed  completely  and  consistently 
describe  the  models  being  used  for  understanding  a  problem 
(Arnold  et  al,  1991)?  In  particular,  is  a  consistent 
representation  utilized?  It  has  been  argued  that 
representational  shifts  have  stymied  developers  as  they  move 
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from  analysis  to  design.  (Coad  and  Yourdon,  1991)  A  solution 


is  arrived 

at 

"by 

applying  a  uniform  underlying 

representation 

for 

organizing  data  and 

its  exclusive 

processing 

that 

of 

Classes  and  Objects 

within  those 

Classes .  .  .  .  " 

(Coad 

and 

Yourdon,  1991,  pg. 

21)  Again, 

approaches  vary  according  to  the  philosophic  adherence  to  pure 
00  concepts  and  techniques. 

B.  OO  DEVELOPMENT  APPROACHES 

00  practitioners  are  in  search  of  methods  whose  logic  is 
infused  from  the  start  by  00  constructs  and  objectives.  Given 
the  lack  of  standardization  in  the  field,  it  is  not  surprising 
that  there  exist  wide  differences  in  00  development 
approaches.  The  positions  advanced  by  some  of  the  better- 
known  00  advocates  will  now  be  reviewed. 

1 .  Coad/Yourdon 

In  apprehending  the  real  world,  men  [people] 
constantly  employ  three  methods  of  organization,  which 
pervades  all  their  thinking.  (Coad  and  Yourdon,  1991, 
pg.  1) 

Coad  and  Yourdon  proceed  on  the  assumption  that 
analysis/design  thinking  should  parallel  the  patterns  by  which 
people  ordinarily  organize  knowledge.  The  three  methods  of 
organizing  knowledge  are  (Coad  and  Yourdon,  1991) :  (1)  objects 
and  their  attributes;  (2)  distinctions  between  objects  and 
component  parts;  and,  (3)  distinctions  between  classes  of 
objects.  This  knowledge  is  garnered  in  OOA  through  five 


activities  (Goad  and  Yourdon,  1991):  (1)  finding  class-&- 
objects;  (2)  identifying  structures/  (3)  identifying  subjects; 
(4)  defining  attributes;  and  (5)  defining  services*.  The 
activities  can  be  pursued  in  any  order,  and  generally  move 
from  higher  to  lower  levels  of  abstraction. 

OOD,  in  the  Coad/Yourdon  approach,  takes  the  results 
of  OOA  and  further  refines  the  organization  of  knowledge. 
Additionally,  specific  requirements  of  the  application  are 
introduced  by  organizing  design  into  four  components  (Goad  and 
Yourdon,  1991) :  (1)  the  problem  component,  which  models  the 
real-world  problem  space;  (2)  the  human  interaction  component, 
which  models  how  a  human  will  command  system  and  how  a 
system  will  present  information;  (3)  the  task  management 
component,  which  addresses  concurrency  control;  and,  (4)  the 
data  management  component,  which  provides  the  infrastructure 
for  the  storage  and  retrieval  of  objects  from  a  data 
management  system.  OOA  results  form  the  bulk  of  the  problem 
domain  component . 

As  analysis  and  design  is  refined,  particular  emphasis 
should  be  applied  to  reducing  connections  between  objects  and 


®Class-&-ob jects  assume  their  usual  meaning,  structures 
include  generalization-specialization  and  whole-part 
structures,  subjects  are  mechanisms  for  guiding 
analysts/experts  through  complex  models,  attributes  are  data 
maintained  about  the  state  of  an  object,  and  services  are 
behaviors  objects  are  responsible  for.  (Goad  and  Yourdon, 
1991) 
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between  classes.  (Coad  and  Yourdon,  1991)  Specifically,  they 
recommend  controlling  the  following  forms  of  coupling  (Coad 
and  Yourdon,  1991) :  (1)  interaction  coupling  (limiting 
parameters  in  messages  to  three  or  fewer,  and  simplifying  the 
number  of  messages  sent  and  received  by  individual  objects) ; 
and,  (2)  inheritance  coupling  (maximizing  superclass/subclass 
connections  along  generalization-specialization  lines) .  The 
authors  also  recommend  that  cohesion  be  maximized  as  follows: 
(1)  services  should  carry  out  one  function;  (2)  classes  should 
contain  no  extra  attributes  or  services;  and,  (3)  inheritance 
should  portray  specialization  cohesion,  not  arbitrary 
relationships . 

Though  great  emphasis  is  placed  upon  the  use  of  a 
unifying  00  notation,  comparatively  little  advice  is  directed 
toward  actual  development  tools.  The  authors  do  advocate 
utilizing  a  CASE  tool  for  OOA,  and  also  recommend  using 
summary  cards  for  manually  conducting  analysis  and  design. 
(Coad  and  Yourdon,  1991) 

2 .  Booch 

Object-oriented  design  is  not  a  process  that  starts 
with  a  requirements  specification,  ends  with  a 
blueprint  for  implementation,  and  requires  a  miracle 
somewhere  in  between.  We  suggest  that  it  allow  an 
evolutionary  development ,  a  view  consistent  with 
Boehm's  spiral  model  of  software  development .  (Booch, 
1991,  pg.  190) 

We  believe  that  Booch' s  discussion  on  OOA  and  OOD 
(Booch,  1991)  is  as  much  a  diatribe  on  00  philosophy  as  it  is 


on  00  techniques.  Particular  care  is  taken  to  emphasize  that 
the  00  approach  to  software  development  is  a  voyage  of 
discovery  and  invention  for  which  there  are  no  hard  and  fast 
rules.  Consequently,  considerable  effort  is  spent  explaining 
the  limited  applicability  of  structured  techniques  and 
waterfall  lifecycle  development.  Structured  techniques  tend 
to  reflect  a  bias  toward  algorithmic  decomposition 
inappropriate  to  real-world  modeling  of  interacting  objects, 
and  the  waterfall  lifecycle  is  a  "...fundamentally  poor 
process,  and  generally  violates  many  of  the  principles  of 
sound  engineering  practice."  (Booch,  1991,  pg.  189) 

The  foundation  of  the  Booch  approach  is  the  isolation 
and  iterative  refinement  of  problem  abstractions.  He  directly 
confesses  that  00  development  is  a  fuzzy  process  in  which 
domain  expertise,  experience,  and  intuition  all  play  a  role  in 
uncovering  relevant  abstractions  at  appropriate  levels  of 
detail.  In  describing  this  evolutionary  process,  he 
highlights  four  prominent  activities  and  illustrates  several 
techniques,  as  described  in  the  following  subsections. 

Development,  for  Booch,  focuses  on  defining  three 
principal  constructs:  objects,  classes,  and  mechanisms.  The 
following  subsections  review  Booch' s  suggested  techniques  and 
organizing  activities. 


a.  TachniquGs/Notation 


Booch  underlines  the  need  for  taking  multiple 
views  on  complex  systems.  (Booch,  1991)  Hence,  he  advocates 
the  use  of  the  following  diagrams:  class,  object,  module,  and 
process.  The  first  two  diagrams  describe  the  logical  view  of 
a  system  while  the  last  two  describe  the  physical  structure  of 
a  system.  These  diagrams  capture  static  semantics.  Dynamic 
system  properties  are  captured  in  state  transition  diagrams 
and  timing  diagrams.  Collectively,  these  techniques  preserve 
the  knowledge  garnered  during  the  four  organizing  activities. 

Class  diagrams  indicate  class  relationships'’, 
class  utilities^*^,  class  categories'^,  superclasses,  fields, 
and  operations.  State  transition  diagrams  show  the  state 
space  of  a  class  -  events  causing  state  transitions.  Object 
diagrams  "...show  the  existence  of  objects  and  their 
relationships  in  the  logical  design  of  a  system,  and 
illustrate  the  semantics  of  key  mechanisms  in  the  logical 
design."  (Booch,  1991,  pg .  169)  Hence,  object  diagrams  are 


’class  relationships  include  inheritance,  instantiation, 
using,  and  metaclass  relationships.  (Booch,  1991) 

^”Class  utilities  are  free  subprograms.  (Booch,  1991) 
That  is,  they  are  operations  which  are  not  meaningfully 
encapsulated  by  any  particular  object.  Instead,  these 
operations  are  grouped  into  utility  classes  from  which  they 
are  accessible,  but  cannot  be  redefined.  (Booch,  1991) 

'^Class  categories  are  logical  collections  of  classes. 
Each  class  within  a  category  has  an  associated  visibility: 
private  to  the  category,  externally  visible,  or  imported  from 
another  category.  (Booch,  1991) 
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used  to  depict  object  properties,  relationships,  visibility, 
and  message  synchronization.  Timing  diagrams  indicate  the 
flow  of  control  among  collaborating  objects.  Module  diagrams 
show  the  allocation  of  classes  and  objects  to  modules,  and 
module  visibility.  Booch  uses  subsystems  to  group  logically 
related  modules.  Finally,  process  diagrams  describe  processor 
allocation  for  applications  with  concurrent  tasks, 
b.  Activities 

Booch  maintains  that  four  activities  typify  00 
development  (Booch,  1991) :  (1)  identify  classes  and  objects  at 
a  given  le^'^el  of  abstraction;  (2)  identify  the  semantics  of 
classes  and  objects;  (3)  identify  relationships  among  classes 
and  objects;  and,  (4)  implement  classes  and  objects.  The 
first  activity  involves  "...the  discovery  of  key  abstractions 
in  the  problem  space  and  the  invention  of  important  mechanisms 
that  provide  the  behavior  required  of  objects  that  work 
together."  (Booch,  1991,  pg.  191)  The  second  activity 
"...establishes  the  meanings  of  classes  and  objects,  viewing 
each  class  from  the  perspective  of  its  interface."  (Booch, 
1991,  pg.  192)  The  third  activity  establishes  "...how  things 
interact  within  the  system."  (Booch,  1991,  pg.  193)  Finally, 
the  fourth  activity  involves  "...design  decisions  concerning 
the  representation  of  the  classes  and  objects  we  have 
invented,  and  allocating  classes  and  objects  to  modules,  and 
programs  to  processors."  (Booch,  1991,  pg .  195) 
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3.  Wirfs-Brock 


Model  your  design  as  clients  and  servers  who 
collaborate  in  ways  specified  by  contracts . 

(Wirfs-Brock,  Wilkerson,  and  Wiener,  1990,  pg .  32) 

The  Wirfs-Brock  approach  to  design  squarely  focuses  on 
maximizing  and  preserving  encapsulation.  (Wirfs-Brock  and 
Wilkerson,  1989)  The  client-server  concept  moves  analysis 
toward  a  responsibility-driven,  contract  perspective  on  entity 
interactions  which  forces  analysis  and  design  away  from 
implementation/structural  details  and  closer  to  behavioral 
abstraction.  (Wirfs-Brock  and  Wilkerson,  1989) 

Analysis  in  the  exploratory  phase  of  system  design 
moves  in  the  following  directions  (Wirfs-Brock,  Wilkerson,  and 
Wiener,  1990):  (1)  find  objects;  (2)  determine  object 
responsibilities;  and,  (3)  determine  object  collaborations^^. 
Heuristics  and  guidelines  are  offered  to  conduct  the  process. 
It  is  recommended  that  class  cards  be  maintained  to  record 
information  about  classes,  class  responsibilities,  and 
collabora^ ions . 

Wirfs-Brock  proposes  that  the  next  phase  of  design 
focus  on  structuring  inheritance  hierarchies  using  hierarchy 
graphs,  Venn  diagrams,  and  contract  analysis.  (Wirfs-Brock, 


^^Collaborations  entail  class  interactions.  Such 
interactions  are  uncovered  by  analyzing  class  communication 
paths,  particularly  is_part_of,  has_knowledge_of ,  and 
depends_upon  communication.  (Wirfs-Brock,  Wilkerson,  and 
Wiener,  1990) 


Wilkerson,  and  Wiener,  1990)  During  this  phase  many 
distinctions  are  drawn  out  (Wirf s-Brock ,  1990) :  (1)  abstract 
and  concrete  classes  are  determined;  (2)  'kind  of' 
hierarchies  are  built  in  which  common  responsibilities  are 
moved  up  the  hierarchy,  abstract  classes  are  added,  and 
unnecessary^^  classes  are  eliminated;  (3)  contract  analysis 
directs  the  reassignment  of  responsibilities,  and  the 
uncovering  of  new  responsibilities;  (4)  class  cohesiveness  is 
maximized;  and,  (5)  the  number  of  class  contracts  is 
minimized.  The  overriding  objective  is  that  "...each  class 
have  a  single,  overarching  purpose;  each  class  should  serve 
one  main  function  in  the  system  of  wh.  :;h  it  is  a  part." 
(Wirf s-Brock ,  Wilkerson,  and  Wiener,  1990,  pg.  121) 

Finally,  and  most  interestingly,  collaboration  graphs 
and  subsystem  cards  are  employed  to  streamline  collaborations 
among  classes^V  (Wirf s-Brock,  Wilkerson,  and  Wiener,  1990) 
Again,  heuristics  and  guidelines  (emphasizing  collaboration 
analysis)  are  offered  to  assist  in  identifying  subsystems. 
Proposals  include  the  following  (Wirf s-Brock,  Wilkeison,  and 
Wiener,  1990) :  (1)  drawing  collaboration  graphs;  (2) 

^^Unnecessary  classes  are  those  which  do  not  add 
functionality.  (Wirf s-Brock,  Wilkerson,  and  Wiener,  1990) 

^^Collaboration  graphs  describes  communication  paths  among 
classes,  and  subsystem  cards  describe  a  subsystem's 
responsibilities  (contracts)  and  the  class  to  which  the 
contract  is  delegated.  (Wi rf s-Brock ,  Wilkerson,  and  Wiener, 
1990) 
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determining  strongly  coupled  classes  (including  transitively 
coupled  classes) /  (3)  simplifying  and  minimizing  interactions; 

(4)  minimizing  subsystem  responsibilities  delegated  to  a 
class;  and,  (5)  minimizing  contracts  supported  by  a  subsystem. 
The  general  idea  is  to  efficiently  distribute  responsibilities 
throughout  the  hierarchies  on  the  basis  of  contract 
considerations  stimulated  by  subsystem  analysis. 

C.  RECOMMENDED  00  ANALYSIS  AND  DESIGN  METHODS 

The  00  methodology  for  representing  knowledge  about  real- 
world  objects  is  comparatively  straightforward.  However, 
determining  the  relex'ant  objects  and  their  systematic 
relationships  is  difficult.  A  particular  sticking  point  is 
the  lack  of  strategic  thinking  on  systematic  organization. 
This  is,  perhaps,  unavoidable  for  a  methodology  that  selects 
objects  and  not  processes  as  the  analytic  ambit. 

There  are  no  rigid  formulas  for  conducting  OOA  and  OOD . 
As  demonstrated  by  the  various  approaches  discussed  in  the 
previous  section,  these  steps  iteratively  inform  and  improve 
one  another.  However,  certain  themes  can  be  culled  which  can 
be  applied  as  a  'backbone'  upon  which  tailored  modifications 
can  be  extended.  These  themes  can  be  thought  of  as 
recommendations  for  organizing  OOA  and  OOD: 

'’In  a  concession  to  structured  design,  functionally 
decompose  a  system  into  its  major  constituent 
subsystems.  This  decomposition  should  serve  as  a 
checklist  against  which  the  actual  evolving  design 
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can  be  assessed  to  ensure  that  principle  subsystem 
responsibilities  are  accounted  for. 

oComplement  system  analysis  with  a  parallel  analysis 
of  supporting  application  requirements  -  concurrency 
control,  interface,  and  database  management. 
Maximize  reuse  of  previously  designed  application 
code.  When  possible,  allow  application  support 
objects  to  perform  subsystem  responsibilities^^. 

“Analyze  principle  subsystem  responsibilities. 

“Identify  problem  domain  object s /classes .  Subject 
experts,  and  prior  designs  should  be  exploited  to 
the  maximum  extent  possible. 

“Analyze  principle  object  responsibilities.  Note 
collaborations  among  objects^*. 

“Analyze  object  variables.  Decide  state  information 
that  each  object  needs  to  preserve  to  fulfill 
responsibilities.  Account  for  variables  shared  by 
objects,  variables  that  can  be  calculated,  and 
variables  that  can  be  decomposed^' .  (dePaula  and 
Nelson,  1991) . 

“Group  objects  into  subsystems.  Note  that  an  object 
may  participate  in  more  than  one  subsystem. 

“Check  to  ensure  that  cooperating  objects  account  for 
behavior  expected  from  respective  subsystems.  Adjust 
object  collaborations  to  achieve  efficient 
distribution  of  systeni  responsibilities:  promote 
tight  object/class  cohesion,  minimize  object/class 


^^Integrating  problem  domain  responsibilities  into 
ap  lication  object  responsibilities  is  one  of  the  more  subtle 
an  '  difficult  tasks  faced  by  the  analyst /designer . 

^'Analysis  should  allow  for  decisions  already  embedded  in 
available  libraries. 

'  Variable  decomposition  takes  account  of  composition 
relationships.  (deFaula  and  Nelson,  1991) 


linkages  within  a  subsystem,  and  reduce  the  number 
of  message  parameters  where  possible^®. 

oGroup  classes  into  specialization  hierarchies^®. 
This  presupposes  a  decision  about  the  semantics 
which  will  control  the  formulation  of  specialization 
relationships . 

o Streamline  class  hierarchies.  This  includes 
segregating  abstract  from  concrete  classes^®, 
factoring  common  methods  as  high  as  possible,  and 
eliminating  unnecessary  classes.  (dePaula  and 
Nelson,  1991)  Note  that  common  protocol  design  will 
include  decisions  about  virtual  and  pure  virtual 
features . 


Tools  for  assisting  analysis/design  can  be  located  in  the 
various  approaches  previously  listed.  CASE  tools  created 
specifically  fox  00  purposes  should  be  used  when  available. 
However,  when  considering  CASE  tools,  many  of  the  issues 
discussed  in  Section  A  need  to  be  carefully  assessed. 

These  recommendations  constitute  a  starting  point.  An 
analyst  must  first  ensure  that  a  strong  foundation  in  00 
techniques  and  philosophy  has  been  acquired  -  knowledge  which 
extends  beyond  mere  facility  with  a  particular  pure  or  hybrid 


^®An  object  overburdened  with  subsystem  responsibilities 
suggests  that  the  object /class  should  be  decomposed  into 
smaller,  more  specialized  object s /classes .  This  will  assist  in 
promoting  object/class  cohesion. 

'®Note  that  hierarchy  construction  requires  prior 
consideration  of  OOL  selection  -  single  or  multiple 
inheritance  strategies  must  be  decided.  Also,  multiple 
inheritance  strategies  must  account  for  resolutions  to 
conflicts  discussed  in  Chapter  II. 

^"Abstract  classes  should  formulate  a  common  protocol . 
Additionally,  abstract  classes  should  not  inherit  from 
concrete  classes.  (dePaula  and  Nelson,  1991) 


OOPL.  This  foundation  will  be  needed  to  resolve  many  of  the 
00  mechanism  conflicts  which  are  addressed  in  Chapter  V. 
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IV.  FUNCTIONAL  DECOMPOSITION  AND 
SUBCLASS  RESPONSIBILITY 

A.  FUNCTIONAL  DECOMPOSITION 

Chapter  III  considered  the  applicability  of  structured 
design  techniques  to  00  problems.  Although  the  emphasis  of 
structured  design  falls  squarely  upon  procedures  and  not 
objects,  many  of  the  concerns  which  prompted  structured  design 
in  the  first  place  (modularity,  flexibility,  reliability, 
cohesion,  coupling)  receive  corresponding  importance  in  OOP. 
Hence,  it  is  not  unreasonable  to  expect  that  some  of  the 
arguments,  if  not  techniques,  of  structured  design  applies  to 
OOP.  This  section  addresses  one  area  which  merits  attention: 
functional  decomposition. 

1 .  Functional  Decomposition  and  Subclass  Responsibility 

It  has  been  noted  that  the  pure  00  methodological 
framework  "...does  not  totally  neglect  structured  tools  and 
experience;  rather,  it  defers  it  to  a  more  detailed  design 
level."  (Henderson-Sellers  and  Constantine,  1991,  pg .  14) 

.Specifically,  design  of  methods  is  "...essentially  identical 
to  structured,  functional  decomposition  as  developed  over  the 
last  twenty  years  or  so."  (Henderson-Sellers  and  Constantine, 
1991,  pg.  14)  Observe  that  "this  does  not  contradict  the 
object-oriented  paradigm  since  at  this  level  the 
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implementation  of  the  features  is  hidden  and  changes  in  the 
implementation  therefore  have,  at  least  in  principle,  no 
repercussions  on  the  rest  of  the  software  system."  (Henderson- 
Sellers  and  Constantine,  1991,  pg.  14) 

Several  software  qualities  and  heuristics  have  been 
identified  as  conducive  to  better  structured  designs.  (Yourdon 
and  Constantine,  1978)  In  the  context  of  structured  design, 
a  module  is  identified  with  a  single  functional  purpose.  The 
unifying  purpose  varies  according  to  the  organizing  strategy 
adopted  (for  example,  transact' on  analysis  or  transform 
analysis) .  Modules  are  decomposed  (procram  structures  are 
organized)  by  assessing,  among  other  ,hings,  factoring', 
cohesion^,  and  coupling^.  Given  the  identification  of  modules 
with  functional  purpose,  this  resolves  into  a  process  of 
functional  decomposition. 

Cohesion,  coupling,  and  factoring  are  also  relevant  to 
the  design  of  methods.  Subclass  responsibility  was  previously 


'Factoring  is  a  term  which  describes  the  degree  to  which 
control  and  coordination  functions  are  performed  by  higher- 
level  modules  in  a  hierarchy  (produced  by  modular 
decomposition) ,  and  processing  is  delegated  to  subordinant 
modules.  (Yourdon  and  Constantine,  1978) . 

^Cohesion  reflects  a  semantic  or  procedural  unity 
exhibited  by  statements  which  suggests  bundling  into  a  single 
module  is  appropriate. 

'Coupling  is  a  measure  of  the  degree  to  which  separate 
program  elements  are  independent  of  one  another.  (Yourdon  and 
Constantine,  1978) 
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defined  (Chapter  II)  as  a  situation  in  which  ancestor  class 
methods  rely  on  the  knowledge  that  descendants  must  implement 
certain  methods.  As  such,  a  design  providing  for  subclass 
responsibility  can  be  viewed  as  a  subset  of  functional 
decomposition . 

Figure  1  can  be  used  to  illustrate  subclass 
responsibility.  Superclass  A  contains  methods  1  and  2  while 
subclasses  B,  C,  and  D  contain  methods  3  and  4,  5  and  6,  and 
3  and  7  respectively.  Method  1  invokes  method  3,  but  Class  A 
does  not  implement  it.  This  situation  therefore  requires  that 
Class  A  be  implemented  as  an  abstract  class,  or  that  an 
instance  of  Class  A  cannot  call  method  1.  The  invocation  of 
method  3  takes  the  form  s6lf->3.  Observe  that  subclasses  B 
and  D  implement  method  3,  but  that  subclass  C  does  not.  Thus, 
Class  C,  like  Class  A,  must  either  be  an  abstract  class  or 
instances  of  Class  C  cannot  call  method  1.  Finally,  methods 

4,  6,  and  7  simply  indicate  that  other  methods  may  be 

Class  A 

method  1  | 

method  2  i 

I 

I 

I 

[ - 1- - 1 

Class  B  Class  C  Class  D 

[  method  3  method  5  method  3 

method  4  method  6  method  7 

r _ _  _ _ _ _ 

Figure  1:  Subclass  Responsibility 
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implemented  by  subclasses.  In  this  example,  these  other 
methods  do  not  interact  with  method  3  or  method  1 .  The 
following  subsections  review  problems  associated  with  subclass 
responsibility  and  use  of  cohesion,  coupling,  and  factoring  to 
reduce  these  problems. 

a .  Siibclass  Responsibility 

Subclass  responsibility  does  not  fit  easily  into 
the  design  recommendations  listed  in  Chapter  III.  First,  as 
illustrated  in  Figure  1,  it  is  questionable  whether  subclasses 
should  be  allowed  to  exclude  methods  assumed  to  be 
implemented.  This  may  be  possible  for  liketype  systems  as 
described  in  Chapter  II,  but  should  not  be  attempted  in 
dynamically  typed  languages.  A  class  may  legally  inherit, 
but  not  implement  a  pure  virtual  method.  In  a  strongly  typed 
language  such  as  C++,  such  classes  are  automatically 
recognized  as  abstract  classes.  Hence,  run-time  errors  will 
not  occur  since  objects  from  these  classes  cannot  be 
instantiated^.  No  such  protective  mechanisms  are  available  in 
dynamically  typed  languages  like  Smalltalk.  Consequently,  the 
onus  is  shifted  to  the  designer  to  ensure  that  all  possible 
avenues  for  arriving  at  such  an  invocation  are  precluded. 

Second,  subclass  responsibility  clearly 
establishes  an  undesirable  coupling  between  ancestor  and 

^It  is  assumed  the  design  recommendation  that  abstract 
classes  not  inherit  from  concrete  classes  is  also  observed. 
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descendent  classes.  It  requires  a  cooperative  design  effort 
between  respective  class  designers.  Notice  that  it  also 
requires  that  descendent  classes  have  some  awareness  of 
ancestor  class  implementations  (i.e.,  method  3  occurs  in  the 
specific  context  of  method  1) . 

Third,  in  languages  such  as  C++,  method  3  must  be 
declared  (although  not  defined)  in  Class  A.  Why  not  supply 
default  behavior,  perhaps  an  error  message,  to  protect 
designers  of  descendent  classes?  In  other  words,  employ 
virtual  functions  which  can  be  overridden  by  descendent 
classes. 

Fourth,  it  was  asserted  in  Chapter  III  that 
abstract  classes  should  provide  a  common  protocol  and  define 
common  behavior  for  descendent  classes.  Again,  if  subclass 
responsible  behaviors  (for  example,  method  3)  are  not 
applicable  to  all  concrete  descendants  (for  example.  Class  C)  , 
they  should  not,  under  this  formulation,  be  designed  into  the 
concerned  abstract  class. 

Finally,  designers  must  carefully  consider  the 
visibility  of  subclass  responsible  behaviors.  Given  the 
linkages  (discussed  below)  established  by  subclass  responsible 
design,  it  is  questionable  whether  such  behaviors  should  form 
part  of  the  external  interface. 

The  preceding  discussion  leads  t th“  following 
recommendations  when  employinq  subclass  responsible  designs: 
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(1)  classes  such  as  Class  A  in  Figure  1  should  be  abstract 
classes;  (2)  every  concrete  descendant  class  should  implement‘d 
the  subclass  responsible  behavior;  and,  (3)  carefully  consider 
whether  to  include  abstract  classes  which  inherit  from 
concrete  classes  implementing  subclass  responsible  behaviors, 
b.  Design  Heuristics  for  Siibclass  Responsibility 

Should  designers  elect  to  organize  behavior  using 
subclass  responsibility,  the  techniques  of  structured  design 
can  be  used  to  structure  solutions.  The  starting  point  is  a 
class  with  one  or  more  methods  which  are  excessively  large'^, 
or  not  conceptually  unified.  Structured  techniques  can  then 
be  applied  to  decompose  these  methods. 

(1)  Cohesion.  "Cohesion  is  the  measure  of  _he 
strength  of  functional  relatedness  of  elements  within  a 
module."  (Page-Jones,  1988,  pg.  83)  Modular  elements^  are 
related  (or  associated)  by  virtue  of  some  property  they  have 
in  common.  (Yourdon  and  Constantine,  1978)  Included  among 


^Either  directly  or  through  inheritance  from  another 
concrete  class. 

*The  computer  science  literature  is  generally  ambiguous 
about  what  constitutes  an  overly  large  module  since  the 
magnitude  is  influenced  by  notions  of  cohesion.  However,  half 
a  page,  about  30  lines  of  program  statements  in  a  high  le'”-el 
language,  has  been  offered  as  tolerable.  (Page-Jones,  1988) 

In  the  present  context,  modules  refer  to  methods  and 
element  s  refer  to  statements  or  gr  oup^s  o  f  statements  in  a 
method . 
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these  associative  properties  are  the  following:  functional®, 
sequential®,  communicat  ional'",  procedural”,  temporal”, 
logical”,  and  coincident aJ ” . 

In  the  context  of  a  class,  a  method  is  associated 
with  a  single  form  of  behavior.  Hence,  functional  cohesion 
should  determine  whether  elements  are  bundled  into  a  single 
method.  Although  sequential  and  communicat ional  cohesion  have 
also  been  supported  as  reasons  for  bundling  elements  into  a 
sinule  module  (Page-Jones,  1988),  these  are  data-oriented 
associations  which  are  incompatible  with  the  behavioral 
underpinning  to  00  methods.  In  passing,  it  should  be  noted 


^Functional  cohesion  relates  program  elements  that  all 
contribute  to  the  accomplishment  of  a  single  problem-related 
task.  (Page-Jones,  1988) 

’Sequential  cohesion  involves  activity  such  that  output 
from  one  activity  serves  as  input  to  the  next  activity.  (Page- 
Jones,  1988) 

”Communicat ional  cohesion  relates  elements  which  all 
share  the  same  input,  or  contribute  to  the  same  output.  (Page- 
Jones,  1988) 

“Procedural  cohesion  relates  activities  associated  by 
control  flow.  (Page-Jones,  1988) 

“Temporal  cohesion  involves  activities  related  in  time. 
(Page-Jones,  1988) 

“Logical  cohesion  relates  activities  of  the  same  general 
category  (for  example,  means  of  transport),  the  execution  of 
which  is  determined  from  outside  the  module.  'Page-Jones, 

1988) 


“Coincidental  cohesion  relates 
meaningful  relationship  to  one  another. 


activities  with  no 
(Page-Jones,  1988) 
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that  the  separate  behaviors  which  are  combined  by  these  two 
forms  of  cohesion  are  not  available  to  ther  methods  or  to 
descendent  classes^'.  The  other  forms  of  cohesion  represent 
looser  associations  which  should  not  be  used  to  build  methods. 
Consequently,  elements  that  cannot  be  tied  together  through 
functional  cohesion  should  be  broken  out  as  distinct  methods. 

The  problem  remains,  however,  of  elements  within 
a  functionally  cohesive  method  which  represent  pieces  of 
behavior  which  are  conceptually  the  same^',  but  which  require 
different  implementations  depending  upon  the  objects  to  which 
they  are  applied.  These  statements,  not  surprisingly,  can  be 
broken  out  using  subclass  responsibility 

(2)  Coupling.  Implicit  in  the  notion  of  cohesion 
is  the  idea  that  large,  uncohesive  modules  should  be 
partitioned  into  smaller,  conceptually  uni fied  modules .  (Page- 
Jones,  1988)  "It  is  vital  that  this  partitioning  should  be 
carried  out  in  a  way  that  the  modules  are  as  independent  as 
possible  -  this  is  the  criterion  of  coupling...."  (Page- 
Joncs,  1988,  pg .  57)  Coupling  in  the  00  environment  has  so 
far  been  described  as  a  linkage  established  between  two 


^^These  behaviors  can  be  made  available  by  duplicating 
der^citions  (i.e.,  defining  methods  which  implement  the  same 
behavior) . 

''^Yourdon  and  Constantine  describe  these  as  "processing 
elements"  in  distinction  to  instructions  oi  statements. 
(Yourdon  and  Constantine,  1978,  pg .  97) 
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classes  on  the  basis  of  the  knowledge  possessed  by  one  class 
of  the  other's  external  and  internal  interfaces.  Chapter 
V/Section  A  analyzes  other  forms  of  00  coupling,  discussing 
aberrant  forms  of  coupling  in  which  classes  possess  direct 
knowledge  of  implementation  details. 

It  was  previously  suggested  that  subclass 
responsibility  creates  an  undesirable  coupling  by  requiring 
subclass  designers  to  understand  in  what  contexts  subclass 
responsible  beliar'iors  are  invoked.  This  is  evidenced  by  the 
fact  that  such  behaviors  have  a  specific  role  to  play  in 
completing  the  behavior  exp'ected  of  the  calling  method,  and 
generally  are  not  designed  to  fulfill  independent  behavioral 
duties  (i.e.,  subclass  responsible  methods  approximate  what 
were  termed  auxiliary  methods  in  Chapter  II) . 

Structured  techniques  usefully  define  two  forms  of 
coupling  that  should  be  avoided  or  minimized  when  designing 
subclass  responsible  relationships.  First,  data  coupling 
should  be  minimized.  Data  coupling  is  a  linkage  achieved 
tlirough  parameter  passing.  At  issue  is  how  many  parameters 
are  passed,  what  details  are  revealed  by  the  parameters,  and 
^low  the  parameters  are  subsequently  used  (side  effects)  . 
Designers  should  avoid  passing  large  numbers  of  parameters, 
and  should  preserve  encapsulation  of  structural  details. 
Second,  control  coupling  entails  the  passing  of  information 
intended  to  control  the  internal  logic  of  the  receiving 
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module.  Control  coupling  requires  that  the  calling  method 
have  knowledge  about  the  details  of  subclass  responsible 
behaviors.  This  has  obvious  implications  for  modifications 
effected  on  subclass  responsible  behaviors  and  should  be 
avoided.  Moreover,  these  complexities  multiply  as  fan  out*^ 
increases . 

(3)  Factoring.  "Factoring  is  the  separation  of  a 
function  contained  as  code  in  one  module  into  a  new  module  of 
its  own"  (Page-Jones,  1988,  pg.  103)  It  is  used  to  achieve 
one  or  more  of  the  following  (Page-Jones,  1988) :  reduce  module 
size,  achieve  top-down  design,  avoid  function  duplication, 
separate  work  from  management,  generalize  modules,  simplify 
implementation.  Note  that  factoring  includes  more  than 
subclass  responsibility.  Hence,  once  a  reason  for  pursuing 
factoring  has  been  selected  (reduce  module  size,  generalize 
modules,  etc.),  structured  techniques  such  as  DFDs  and 
structure  charts  can  be  used  to  examine  methods  and  determine 
the  merits  of  alternatives. 

Several  issues  need  to  be  clarified,  however, 
before  factoring  is  attempted.  First,  a  rationale  must  be 


'Fan  out  is  a  magnitude  describing  the  number  of  modules 
subordinate  to  a  higher  level  module.  In  the  present  context, 
fan  out  describes  the  number  of  descendent  classes  defining 
subclass  responsible  behavior  for  a  particular  invocation. 
Note  that  difficulties  are  even  area^e?  if  m'U'^  than  one 
method  in  an  ancest-^r  clas.s  contains  calls  '  subclas.s 
responsible  behavior?. 
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established.  Top-down  design  of  methods  in  a  class  is 
probably  not  a  cogent  reason  for  decomposition.  Module  size, 
of  itself,  is  not  a  sufficient  reason  for  breaking  out 
behavior  (i.e.,  large  does  not  necessarily  mean  uncohesive) . 
On  the  other  hand,  avoiding  function  duplication  and 
generalizing  methods  are  good  reasons  for  decomposing  methods. 

Second,  once  decomposition  has  been  accomplished, 
'le';- is  ions  based  upon  00  considerations  must  be  made  about  what 
to  d"  with  the  results.  Again,  designers  return  to  the 
requirement  for  formulatina  a  methodology  for  allocating 
knowledge  among  classes.  Matching  behavior  to  objects  in  the 
problem  has  often  been  advanced  in  this  thesis  as  one  such 
criterion  (i.e.,  responsibility  drir'en  analysis). 
Nevertheless,  this  rather  facile  solution  requires  substantial 
amplification.  Should  all  the  behaviors  broken  out  by 
decomposition  be  retained  in  the  class  of  the  method  from 
which  they  are  decomposed?  Should  these  behaviors  be 
implemented  as  auxiliary  methods?  Should  designers  avail 
themselves  of  opportunities  (offered  by  some  OOPLs)  to  include 
behaviors  as  stand-alone  functions  and  macros?  Should  non- 
behavioral  considerations  enter  into  the  allocation  of  these 
behaviors  in  a  hierarchy  (for  example,  influencing  binding 
time)?  In  short,  structured  techniques  can  be  used  to  improve 
poorly  desianed  meth-^d.^,  t'u^  this  d':'es  n^*  au^ ':'mat  i  ca  1 1  y 
translate  to  better  d«»sianed  classes  and  hieiar-hies. 
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Subclass  resp'onsibility  appears  to  be  a 
specialized  instance  of  management /work  separation.  The 
ancestor  class  method  decides  some  form  of  behavior  needs  to 
be  invoked,  descendent  class  methods  actually  implement  the 
work.  Management  should  be  executed  without  knowledge  about 
who  (or,  more  accurately,  what)  performs  the  work.  Designers 
can  therefore  employ  structured  techniques  to  isolate 
management /work  relationships  among  functionally  cohesive 
hiehaviors.  Work  can  then  L^e  delegated  to  descendent  classes 
fi.'i  implementation. 
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V.  PARADIGM  CONFLICTS 


The  00  philosophy  concentrates  thought  about  software 
development  directly  on  those  concepts  which  most  forcefully 
impact  the  efficiency  of  the  process  -  modularization, 
abstraction,  information  hiding,  reusability,  extendibility , 
and  maintainability.  It  was  noted  in  the  previous  chapters 
tliat  the  conduct  of  OOA,  OOD,  and  OOP  can  vary  widely 
depending  upon  the  notations,  methods,  and  concepts  used.  00 
practitioners  must  consequently  bear  much  of  the  burden  for 
producing  software  that  realizes  the  favorable  properties 
comprehensively.  This,  in  turn,  implies  that  programmers  and 
designers  should  obtain  a  sound  understanding  of  potential 
language  mechanism  conflicts  and  design  tradeoffs. 

This  chapter  highlights  00  language  features  which  can 
potentially  undermine  the  effective  use  of  information  hiding 
-  the  principle  means  by  which  long-term  maintenance  costs  can 
be  controlled.  Specifically,  attention  is  drawn  to  the 
encroachments  on  information  hiding  produced  by  inheritance'. 
Additionally,  consideration  is  given  to  design  criteria  for 
employing  composition  over  inheritance. 


'The  informat  i:Ti  hidina,  inheritance  reflects 
design  tradeoffs  that  must  be  made  between  information  hidinq 
and  reusability. 


A.  ENCAPSULATION  VULNERABILITIES 


A  certain  degree  of  economy  enters  into  the  design  of  00 
software.  Abstraction,  information  hiding,  and  reusability 
can  be  viewed  as  interdependent  variables  whose  values 
designers  collectively  attempt  to  optimize.  What  constitutes 
a  collective  optimum,  of  course,  is  reserved  to  particular 
design  philosophies.  Nevertheless,  there  is  a  predisposition 
to  consider  information  hiding  as  central  in  any  solution  to 
many  software  lifecycle  pioblems*. 

Abstraction  abets  thinking  that  emphasizes  essential 
properties  over  mundane  details.  From  the  outset,  abstraction 
directs  attention  away  from  implementati  n  details.  Hence, 
abstraction  supports  information  hiding  in  the  sense  that  the 
abstract  conceptual  approach  promotes  design  organization 
which  distinguishes  property  from  detail .  00  designs  and 
programs  exercise  their  abstract  qualities  through  the 
respective  class  interfaces.  Consequently,  designers  must 
understand  OOPL  mechanisms  and  vulnerabilities  that  circumvent 
or  undermine  the  strict  enforcement  of  communication 
controlled  by  interface. 

Inheritance  increases  code  reuse.  To  the  degree  that 
inheritance  mechanisms  depart  from  interface  enforcement, 


‘Software  engineering  evolved  during  the  la^^  l?70's  and 
early  1980' s  in  large  part  due  to  the  explosion  of  software 
maintenance  costs  over  the  product  life-cycle.  (Booch,  1987) 


reuse  is  achieved  at  a  cost:  the  internal  details  of  classes 


are  exposed.  Even  in  situations  of  strict  interface 
enforcement,  inheritance  creates  linkages  among  related 
classes  that  require  careful  attention  when  modifications  are 
effected.  These  reservations  with  respect  to  inheritance  are 
particularly  prominent  for  complex  applications  involving 
highly  developed  class  hierarchies. 

1 .  External  Interface 

Tlie  external  interface  consists  of  those  object 
features  available  to  oL-ject  users  (see  Chapter  III  on 
external  clients) .  Poorly  designed  or  inadequately  enforced 
external  interfaces  can  lead  to  a  reduction  in  information 
hiding . 

a.  ReprBSBntatlon  Access 

The  primary  purpose  of  encapsulation  is  to  hide 
the  structural  details  of  objects.  Limiting  access  to  object 
variables  to  ac.,oss'~r  methods  allows  designers  a  finer  degree 
of  control:  (1)  no  access,  read  only  access,  or  read/write 
access/update  methods  can  be  implemented;  (2)  users  need  not 
have  any  knowledge  of  variable  types;  (3)  polymorphism  can  be 
exploited  to  construct  conversion  methods  for  handling 
variables’;  and,  (4)  variables  can  be  renamed,  removed,  or 

'An  example  would  be  an  object  which  tracks  location. 
The  actual  variables  may  be  placed  in  a  Cartesian  arid.  A 
polymorphic  accessor  method  can  be  designed  which  uses  either 
Cartesian  or  polar  coordinants  to  set  the  value  of  the 
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reinterpreted'*  without  necessitating  a  recompilation  of  user 
code.  (Snyder,  1986) 

OOPLs  or  designers  may  fail  to  insulate  object 
variables  from  direct  access /update  in  several  ways.  First, 
a  language  may  not  offer  mechanisms  to  render  the  structural 
details  private  (i.e.,  they  do  not  encapsulate) .  Second, 
though  a  language  may  provide  an  interface  to  access/update 
variables,  it  ray  not  restrict  the  user  to  this  interface. 
OOPLs  may  allow  direct  access /update  by  variable  name  (such  as 
Simula),  or  may  allow  direct  access /update  through  dot 
notation  (such  as  C+  +  )  .  Third,  designers  may  write  methods 

which  contain  embedded  direct  references  to  variables.  In 
this  case,  users  maintain  an  indirect  capability  for 
representation  access.  This  leads  to  the  curious,  if  not 
obvious,  idea  that  objects  must  be  protected  from  themselves! 
b.  Creation  and  Initialization 

Some  OOPLs  provide  shortcuts  for  object  creation 
and  initialization  which  expose  implementation  details. 
(Micallef,  1988)  Simula,  which  employs  formal  parameters, 
provides  initialization  by  actual  specification  of  values  for 

location  variable.”^. 

^Variable  modification/elimination,  however,  may  require 
reviewing  the  implementation  of  the  accessor  methods  to  ensure 
that  contracted  behavior  is  maintained.  This  class  method 
inspection  necessity  expands  if  other  methods  in  th*^  class  can 
access  variables  directly  (t^y  name  rather  than  through  an 
accessor  method) . 
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the  formal  parameters;  consequently,  the  "number,  type  and 
semantics  of  formal  parameters  are  a  part  of  the  object's 
external  interface."  (Micallef,  1988,  pg .  18)  Flavors  allows 
initialization  methods  which  directly  use  variable  naiaes  as 
keywords.  (Micallef,  1988)  The  preferred  course  to  pursue  in 
these  instances  is  to  separate  object  creation  from  object 
initialization  such  that  variable  access  is  limited  to  the 
body  of  initialization  methods.  (Micallef,  1988)  Again, 
maximum  information  hiding  is  achieved  when  initialization 
methods  must  use  accessor  methods  to  assign  values, 
c .  Auxiliary  Methods 

As  noted  in  Chapter  Il/Section  B,  auxiliary 
methods  are  supporting  operations,  knowledge  of  which  end 
users  do  not  need.  These  methods  should  therefore  not  be  part 
of  the  external  interface.  An  OOPL  should  provide  a  mechanism 
to  render  these  methods  private  to  respective  instantiations 
of  the  object . 

2 .  Internal  Interface 

The  internal  interface  consists  of  those  ancestor 
features  available  to  descendent  classes  by  virtue  of 
inheritance  mechanisms.  Some  languages  offer  the  capability 
of  designating  class  features  as  private  to  instantiating 
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clients,  but  visible  to  inheriting  clients’.  (Micallef,  1988) 
As  with  poorly  designed/enforced  interfaces  to  instantiating 
clients,  similarly  weak  interfaces  to  inheriting  clients  can 
expose  implementation  details.  This  subsection  considers 
interface  vulnerabilities.  Subsequent  sections  discuss  other 
facets  of  inheritance  which  pose  problems  for  information 
hiding . 

a.  RepresBntation  Accoss 

Access  to  superclass  structural  details  should  be 
limited  to  accessor /update  methods  for  the  same  reasons  as 
those  outlined  in  the  previous  section.  Consequently, 
descendent  classes  should  not  be  able  to  directly 
access/update  superclass  variables  by  name  or  dot  notation. 
This  implies  that  superclass  designers  must  cooperate  by 
including  the  appropriate  access/update  methods.  (Snyder, 
1986) 

b.  Etabrnddad  Dlract  Accbss 

Methods  which  can  potentially  be  inherited  should 
utilize  access/update  methods  for  references  to  variables 
embiedded  in  the  methods,  again,  this  results  in  reduced 
linkages  thereby  minimizing  the  effects  of  variable 
modification/elimination.  Plance,  embedded  direct  access/ 

'Specifically,  superclass  features  declared  public  or 
protected  are  visible  to  descendent  classes .  See  Chapter 
Il/Section  C  for  more  on  inheritance. 
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update  is  dangerous  to  both  superclasses  and  descendant 
classes . 

c.  ' Self '/' This'  Invocation 

Some  OOPLs  offer  der’-ices  by  which  an  object  can 
directly  invoke  methods  on  itself.  Smalltalk  employs  the  word 
'self',  "...a  special  variable  representing  the  object  which 
is  the  receiver  of  a  message."  (Smalltalk/V286  Tutorial 
Pioqramming  Han'dbook,  1988,  pg.70)  Similarly,  C  +  +  uses  the 

wi'id  'tills',  "a  pointer  to  the  object  for  which  a  memb'er 
function  is  invoked...."  (Stroustrup,  1987,  pg .  137)  Problems 
aris»,  however,  if  operations  inx'oked  through  this  device  are 
redefined  by  a  class  or  any  of  its  descendants.  {Snyder,  1986) 
An  inherited  method  using  'this'  (or  'self')  may  therefore 
invoke  descendant  class  methods  instead  of  the  intended 
superclass  method. 

Several  opt  ions  can  address  the  problem:  (1) 

•iesianers  of  descendant  classes  can  be  aware  of  inherited 
method  implementations  -  an  undesirable  x'^iolation  of 
information  hiding;  (2)  sup>erclass  designers  can  limit  use  of 
'self'  or  'this'  to  refer  to  private  methods;  and,  (3)  some 
other  languaae  mechanism  can  be  developed  which  allows  an 
operation  invocation  to  specify  the  appropriate  superclass. 
Smalltal/v  provides  a  partial  solution,  allowing  the  word 
'supet  '  to  denote  operation  invc’cation  oy,  a  subclass' 


superclass^.  Smalltalk/V28 6  Tutorial  Programming  Handbook, 
1988)  C++  uses  a  scope  resolution  operator,  to 
specifically  designate  the  source  class  for  method 
implementation.  Use  of  these  devices  ('self',  'this',  or 
' super' )  unavoidably  exposes  inheriting  classes  to 
modification  linkages.  Designers  should  therefore  carefully 
consider  whether  the  convenience  of  these  devices  merits 
potential  information  hiding  lesions. 

3 .  Name  Conflicts 

Some  analysts  maintain  that  name  conflicts  ". . .are  the 
root  of  the  inheritance/encapsulation  problem  as  it  exists  in 
most  OOP  languages."  (Nelson,  Moshell,  a.  i  Orooji,  1991,  pg . 
220)  Complications  occur  when  descendant  classes  override 
ancestor  variables.  The  risk  is  that  overriding  may  happen 


®This  solution  appears  to  push  the  problem  upward  one 
level  in  the  class  hierarchy.  Suppose  a  subclass  A  invokes  a 
superclass  B  method  using  'super' .  Superclass  B  itself  employs 
a  'super'  invocation  to  its  superclass  C.  However,  the  'super' 
call  in  B  to  C  is  to  a  method  which  has  been  redefined  in 
superclass  B.  The  designer  of  subclass  A  has  no  way  of  knowing 
(barring  examination  of  implementation  code)  whether  the 
method  he  would  intend  to  be  invoked  is  in  fact  the  one 
selected.  This  problem  arises  from  the  fact  that  methods  using 
'super'  can  be  inherited  while  'super'  only  refers  to  a 
subclass'  immediate  superclass.  This  solution  also  fails  when 
multiple  inheritance  is  used.  (Snyder,  1986) 


^A  superclass  X  implementation  of  method  Y  could 
therefore  be  invoked  by  descendent  class  Z  using  the  syntax 
X::Y.  Direct  naming,  of  course,  links  inheriting  classes  to 
the  named  class,  exposing  inheriting  classes  to  modifications 
effected  on  the  named  class.  (Stefik,  1986) 
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unintentionally  -  designers  may  be  unaware  of  ancestor  naming 
conventions  because  inherited  variable  names  are  hidden. 
Method  name  conflicts  also  present  potential  problems.  It 
appears,  therefore,  that  subclass  designers  must  possess 
knowledge  about  the  internal  details  of  ancestor  classes. 
This  section  reviews  name  conflicts  as  they  apply  to  single 
inheritance  hierarchies.  Multiple  inheritance  name  conflicts 
are  discussed  in  Subsection  5  of  this  section. 

a .  Variable  Name  Conflicts 

As  a  class  hierarchy  expands,  variable  name 
conflicts  can  become  more  involved.  In  most  conventional 
OOPLs,  new  variables  with  the  same  name  as  inherited  variables 
are  assumed  to  redefine  variables  which  would  otherwise  have 
been  inherited.  (Nelson,  Moshell,  and  Orooji,  1991)  Designers 
consequently  need  to  be  able  to  distinguish  viable 
redefinitions  (overriding)  from  new  variables .  Hence,  "...the 
designer  of  a  class  must  know  all  that  there  is  to  know  about 
the  variables  inherited  from  the  superclass."  (Nelson, 
Moshell,  and  Orooji,  1991,  pg.  220)  Note  that  this  problem 
also  applies  to  inherited  methods  with  embedded  references  to 
variables  which  have  subsequently  been  redefined. 

Jb.  Method  Name  Conflicts 

Method  name  conflicts  foster  ambiguities  similar 
to  those  associated  with  variable  name  conflicts.  Overriding 
may  unintentionally  occur  if  subclasses  define  methods  using 


the  same  names  as  those  of  methods  private  to  the  parent 
class.  A  subtle  permutation  of  this  problem  is  that  there  may 
be  no  way  to  control  methods  used  by  inherited  methods. 
(Nelson,  Moshell,  Orooji,  1991)  An  inherited  method  may 
contain  an  embedded  invocation  to  a  method  which  has  been 
redefined.  Which  implementation  is  subsequently  used  is 
language  dependent®.  (Nelson,  Moshell,  and  Orooji,  1991) 
c.  Name  Conflict  Remedies 

Several  strategies  can  be  employed  to  aJ leviate 
or  eliminate  unintended  name  conflicts.  First,  the  OOPL 
environment  may  include  a  class  hierarchy  browser  which 
permits  investigation  of  inherited  variable  and  method  names®. 


®Nelson,  Moshell,  and  Orooji  (1991)  raise  another 
interesting  (and  amusing)  issue:  every  variable  and  method  in 
an  ancestor  class  may  be  overriden  by  the  time  a  distant 
descendant  class  inherits.  Consequently,  a  class  can  be  an 
ancestor  and  yet  not  supply  one  inherited  feature  to  the 
descendant  class.  Though  the  resolution  of  this  is  a  matter  of 
design  philosophy,  it  raises  questions  as  to  the  nature  of  the 
specialization  which  is  being  designed  into  the  hierarchy. 

’This  can  be  considered  a  violation  of  information 
hiding.  In  particular,  it  may  be  the  case  that  descendant 
classes  are  designed  by  teams  whose  only  intercommunication 
consists  of  knowledge  about  the  external  and  internal 
interfaces.  Nevertheless,  hierarchy  browsers  are  a  common 
tool  which  facilitate  a  potentially  simple  solution  to  name 
conflicts.  Information  hiding  should  not  be  carried  to  such 
extremes  that  development  is  hindered  more  than  assisted.  This 
thought  leads  to  another,  larger  issue.  Though  information 
hiding,  abstraction,  and  modularization  serve  to  promote 
reusability,  the  idea  that  reuse  should  be  attempted  without 
regard  to  inherited  implementation  details  ought  to  be 
approached  with  some  incredulity.  An  obvious  example  concerns 
code  whose  failure  or  aberrant  behavior  can  produce  life  or 
system  threatening  results. 


Designers  are  then  free  to  make  informed  decisions  about 
overriding.  Second,  multiple  copies  of  inherited  variables 
with  the  same  name  can  be  maintained,  each  accessible  only  by 
methods  inherited  through  the  internal  interface^®.  (Nelson, 
Moshell,  and  Orooji,  1991)  Inherited  methods  avert  name 
conflicts  by  continuing  to  function  under  the  interface 
environment  that  existed  in  the  respective  superclass.  Third, 
the  logic  of  inheritance  can  he  restricted  to  extension  only. 
Language  facilities  can  be  structured  which  catch  and  disallow 
name  conflicts.  This  solution,  though  feasible,  would  overly 
constrict  the  inheritance  process.  Moreover,  it  would 
disallow  overriding,  a  mechanism  that  is  sometimes  central  to 
specialization  guiding  the  hierarchy  construction. 

4 .  Hierarchy/Lattice  Modification  Problems 

Chapter  I I /Section  C  reviewed  several  strategies  for 
shaping  class  hierarchies.  Modifications  to  a  class  hierarchy 
potentially  rupture  the  underlying  hierarchy  logic, 
invalidating  the  contracts  which  exist  between  superclass  and 
subclasses.  Information  hiding  cannot  completely  insulate 


^'’Note  that  the  authors  have  defined  the  internal 
interface  to  consist  "...of  those  methods  defined  locally  for 
the  class  and  all  of  the  methods  in  the  external  interface  of 
each  superclass  (but  not  each  ancestor)  of  the  class." 
(Nelson,  Moshell,  and  Orooji,  1991,  pg.  223)  Name  conflicts 
are  avoided  by  attaching  the  superclass  name  to  inherited 
methods.  The  authors  use  the  term  "enheritance"  to  describe 
this  form  of  encapsulated  inheritance.  (Nelson,  Moshell,  and 
Orooji,  1991,  pg .  223) 
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classes  related  through  inheritance  from  the  adverse  impacts 
produced  by  these  modifications.  Consequently,  00  programmers 
need  to  understand  these  linkages  before  attempting  to  modify 
class  hierarchies.  This  caveat  applies  especially  during  the 
maintenance  phase  of  the  software  life  cycle”, 
a.  Inheritance  Visibility 

Inheritance  visibility  refers  to  "...whether  or 
not  the  use  of  inheritance  itself  should  be  part  of  the 
internal  interface  (of  the  class  or  the  objects) .  In  other 
words,  should  clients  of  a  class  (necessarily)  be  able  to  tell 
whether  or  not  a  class  is  defined  using  inheritance?"  (Snyder, 
1986,  pp.  40-41)  At  issue  is  whether  inheritance  should 
remain  strictly  a  mechanism  for  code  reuse,  or  whether  it 
should  enforce  particular  inheritance  strategies  (e.g., 
specialization  and/or  subtyping).  Snyder  (1986)  and  Micallef 
(1988)  contend  that  inheritance  visibility  undermines 
information  hiding  and  reduces  programming  flexibility. 

(1)  Excluding  operations.  "Most  object-oriented 
languages  promote  inheritance  as  a  technique  Tor 
specialization  and  do  not  permit  a  class  to  'exclude'  an 


^^An  approach  to  this  problem  from  a  different  perspective 
argues  that  program-based  testing  of  proven  code  needs  to  be 
reexamined  when  class  hierarchies  are  modified.  (Perry  and 
Kaiser,  1990)  Though  the  discussion  is  technical,  the  authors 
note  various  linkages  produced  by  inheritance  that  require 
retesting  of  code  in  both  modified  and  inheriting  classes  when 
code  is  modified. 
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inherited  operation  from  its  own  internal  interface."  (Snyder, 
1986,  pg.  41)  The  idea  expressed  is  that  specialization 
requires  that  ancestor  features  be  inherited.  Hence,  a  chain 
of  transitive  relationships  is  set  up  in  a  hierarchy.  A 
modification  such  as  redefining  the  superclasses  for  an 
ancestor  class  severely  impacts  descendent  classes  built  on 
the  expectation  of  inherited  features  from  the  now  absent 
superclasses.  Hence,  superclass  modifications  must  account 
for  inheritance  relationships  by  maintaining  a  stable 
interface . 

(2)  Subtyping.  It  was  noted  in  Chapter 
Il/Section  C  that  some  OOPLs  identify  subtyping  with 
inheritance  to  facilitate  static  type-checking.  "If  subtyping 
rules  are  based  on  inheritance,  then  reimplementing  a  class 
such  that  its  position  in  the  inheritance  graph  is  changed  can 
make  clients  of  that  class  type-incorrect,  even  if  the 
external  interface  of  the  class  remains  the  same."  (Micallef, 
1988,  pg.  25)  For  example,  suppose  that  class  Y  is  a  subclass 
of  class  X,  and  that  class  Y  is  redefined  to  be  a  subclass  of 
class  Z  (and  not  of  class  X)  .  Objects  of  class  X  can  no 
longer  be  substituted  for  objects  of  class  Y.  Consequently, 
reusability  is  reduced  and  source  code  may  need  to  be 
rewritten . 

(3)  Remedies.  Inheritance  troubles  traceable  to 
subtyping  mechanisms  (in  which  types  are  identified  with 


classes)  cannot  be  ameliorated^^  -  removing  ancestor  classes 
will  always  invalidate  existing  substitutions  based  upon  type 
relationships  (barring  coercion) .  Clearly,  such  modif ications 
should  occur  during  the  initial  design  (or  rapid  prototyping) 
phase  of  development,  and  not  during  the  maintenance  phase  of 
mature  software  products^^. 

Two  methods  are  available  for  reducing  inheritance 
linkages.  First,  modifications  should  preserve  a  stable 
interface.  This  leads  to  the  notion  that  once  a  class  moves 
into  its  'post-production  phases',  its  interface  should  be 
closed  (except  for  extensions)  .  Fecond,  inheritance 
visibility  should  be  limited  to  a  .  jbclass'  immediate 
superclasses,  and  inherited  methods  should  only  invoke  other 
inherited  methods^^.  (Nelson,  Moshell,  and  Orooji,  1991)  The 


^^It  has  been  noted  that  subtyping  problems  could  be 
handled  by  separating  the  type  hierarchy  from  the  inheritance 
hierarchy.  (Micallef,  1988)  Furthermore,  "...a  formal 
semantic  specification  of  behavior  is  needed  to  be  able  to 
correctly  do  behavioral  subtyping."  (Micallef,  1988,  pg.  27) 
That  is,  some  standard  needs  to  be  agreed  upon  to  relieve 
programmers  of  the  burden  for  selecting  subtyping  rules, 
thereby  automating  subtyping  decisions. 

'^Note  that  elimination  of  any  ancestor  class  from  which 
features  are  inherited  poses  the  same  problem  -  regardless  of 
the  logic  guiding  hierarchy  construction. 

^*It  is  possible  to  'eliminate'  methods  by  coding  null 
implementations.  This  is  a  dangerous  practice,  however,  that 
can  produce  deleterious  results. 

'^Basically,  this  solution  amounts  to  renaming  the 
offending  methods. 
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latter  technique  prevents  subclass  methods  from  'reaching  up' 
a  hierarchy  to  ancestor  variables  or  methods  which  have  been 
overridden  by  superclasses.  In  this  manner,  inheriting 
classes  are  concerned  only  with  inherited  behavior,  and  not 
with  inherited  implementations.  (Nelson,  Moshell,  and  Orooji, 
1991) 

5 .  Multiple  Inheritance 

All  of  the  inheritance  problems  considered  above  also 
apply  to  multiple  inheritance.  In  distinction  to  single 
inheritance,  however,  solutions  are  far  more  complex 
individual  OOPLs  can  create  inheritance  graphs  that  are 
unknown  and  undesired.  As  an  example,  CLOS  (Keene,  1989) 
employs  specificity  rules  for  determining  which  specifiers  for 
individual  slots  will  be  inherited.  Consequently,  the 
definition  of  a  slot  may  represent  an  amalgam  of  specifiers 
inherited  from  different  classes.  Designers  have  to 
investigate  every  superclass  to  determine  the  actual  form  of 
inheritance.  This  example  returns  to  the  larger  problem 
addressed  in  Chapter  2 /Section  C:  what  precedence  rules  does 
an  OOPL  apply  for  determining  what  is  inherited  and  for 
resolving  name  conflicts?  "The  way  this  conflict  is  resolved 
in  some  languages  produces  different  results  if  the 
inheritance  graph  is  changed,  even  though  the  external 
interfaces  of  the  objects  remain  the  same."  (Micallef,  1988, 
pg.  26) 
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For  languages  which  permit  MI,  precedence  rules 
determine  the  shape  of  inheritance  and  resolve  name  conflicts. 
Generally,  such  rules  either  flatten  MI  graphs  into  linear 
chains  by  introducing  a  total  ordering  among  the  classes  and 
then  applying  rules  for  single  inheritance^®,  or  directly 
locate  in  the  MI  graph  inheritable  variables  and  methods^^. 
(Stefik  and  Bobrow,  1986) 

Linear  solutions  will  produce  results  which  depend 
upon  the  decision  criteria  adopted  for  arriving  at  a  total 
ordering.  A  risk  is  that  these  criteria  result  in  chains 
which  do  not  reflect  designer  intentions^®.  (Stefik  and  Bobrow, 
1986)  Hence,  name  conflict  resolution  (and  inheritance  in 
general)  may  not  follow  designer  intentions.  This  compels  the 
designer  to  investigate  the  implementations  of  actually 
inherited  features  to  ensure  consistency  of  purpose. 

Graph-oriented  solutions  require  the  development  of 
graph  traversal  strategies  to  implement  inheritance. 
Additional  rules  must  be  developed  to  handle  name  conflicts 

*^*Such  strategies  are  titled  "linear  solutions."  (Stefik 
and  Bobrow,  1986,  pg .  43)  The  authors  note  that  Flavors  and 
CommonLoops  use  this  strategy. 

^^Such  strategies  are  titled  "graph-oriented  solutions." 
(Stefik  and  Bobrow,  1986,  pg.  42)  The  authors  note  that 
Trellis/Owl  and  extended  Smalltalk  use  this  strategy. 

^®For  example,  a  chain  may  be  established  :i  n  which  an 
immediate  superclass  is  separated  from  a  subclass  by  other 
classes  which  redefine  methods  in  the  superclass. 

^^2 


and  inheritance  from  a  common  ancestor  (non-tree  graphs) . 
Name  conflict  resolution  possibilities  include  the  following: 
(1)  do  not  allow  name  conflicts;  (2)  force  the  subclass  to 
implement  variables/methods  which  override  any  name  conflicts; 
and,  (3)  allow  inheritance  of  all  conflicting  methods^®.  Non¬ 
tree  inheritance  can  be  handled  by  limiting  inheritance  to  one 
set  of  inherited  variables /methods  from  common  ancestors,  or 
multiple  sets  (depending  on  the  number  of  paths  from  an 
ancestor  to  descendant  class) .  The  problem  with  graph- 
oriented  solutions  is  that  inheritance  is  exposed  to 
modifications  in  the  class  hierarchy  (i.e.,  inheritance 
visibility) .  Furthermore,  designers  must  understand  how 
potential  ancestors  implement  methods  (where  name  conflicts 
exist)  to  decide  upon  which  inheritance  strategy  to  pursue. 

The  solutions  to  MI  problems  are  the  same  as  those 
advanced  in  the  previous  section:  a  stable  interface  and 
inheritance  limited  to  immediate  superclasses.  Common 
ancestor  problems  are  probably  best  handled  by  matching  the 
number  of  instance  variable  sets  to  inheritance  paths^”.  Name 


’^Such  strategies  require  some  rules  for  deciding  how  the 
inherited  methods  will  be  invoked.  Possibilities  include 
language  determined  orderings,  and  designer  determined 
orderings . 

^°This  eliminates  a  situation  in  which  multiply  inherited 
methods  from  a  common  ancestor  repeatedly  update  a  single  set 
of  instance  variables  also  inherited  from  the  same  ancestor. 
(Stefik  and  Bobrow,  1986) 


conflicts  can  be  handled  as  before  -  tagging  each  such  method 
with  its  superclass  name  and  restricting  its  visibility  to  the 
interface  of  its  class. 

6 .  Design  Recommendations 

Designers  should  endeavor  to  understand  the 
complications  introduced  by  inheritance  and  minimize  its 
detrimental  aspects  early  in  the  design  phase.  Aside  from 
general  problems  attributable  to  inheritance,  problems 
specific  to  individual  00  languages  should  also  be  thoroughly 
understood.  We  now  offer  the  following  design  recommendations 
for  guiding  inheritance  decisions: 

General  Hierarchy  Prescriptions  - 

oAvoid  constructing  hierarchies  which  include 
multiple  paths  to  common  ancestors. 

oWhen  utilizing  multiple  inheritance,  minimize  the 
number  of  immediate  superclasses. 

olf  the  OOPL  being  used  allows  user  defined 
precedence  ordering^^  for  MI,  avoid  modifying 
superclass  orderings  unless  absolutely  necessary. 

oReduce  the  effects  of  modifications  by  limiting 
the  depth  of  hierarchy  graphs  to  three  or  four 
levels . 

o Always  restrict  variable  access/update  to  methods 
in  the  appropriate  interface. 


^^Many  OOPLs  (such  as  Smalltalk)  determine  a  precedence 
order  based  upon  the  textual  order  in  which  superclasses  are 
listed  in  the  definition  of  a  subclass.  Note  that  this  exposes 
such  subclasses  to  potentially  unintended  side-effects  should 
the  list  be  reordered. 


oMinimize  the  nunibe^-  of  methods  in  both  the 
external  and  internal  interfaces. 

oExploit  public,  protected,  and  private 
mechanisms,  if  available  in  the  OOPL  being  used. 
If  not  available,  attempt  to  directly  design  and 
enforce  these  facilities  into  the  class 
hierarchy . 

OMinimize  the  use  of  self-referential  devices  such 
as  ' self' ,  and  ' this' . 

oMinimize/avoid  use  of  devices  which  allow  direct 
invocations  of  variables/methods  which  are  not 
part  of  the  internal  interface  (e.g.  dot 
notation) . 

o Thoroughly  understand  ancestor  class  visibility 
in  the  OOFL  being  used.  If  prominent,  carefully 
consider  the  consequences  of  changes  to  the  graph 
structure . 

oMaintain  stable  class  interfaces. 

OMinimize  the  number  of  embedded  method 
invocations . 

Name  Conflicts  - 

oWhen  possible,  employ  configuration  management 
techniques  which  limit  naming  conflicts.  If 
available,  exploit  class  browsers  to  uncover  name 
conflicts . 

oCarefully  investigate  the  resolution  mechanisms 
employed  by  the  OOPL  being  used.  Design  classes 
and  modifications  with  these  mechanisms  in  mind. 
For  many  languages,  this  unavoidably  requires 
implementation  visibility  of  the  interface. 

olf  possible,  inherit  all  variables  for  which 
name  conflicts  exist,  using  some  syntactical 
device  such  as  tagging  with  the  superclass 
name  to  di.fferentiate  such  variables.  Limit 
interactions  with  these  variables  to  methods 
inherited  from  the  corresponding  superclass. 


<5 Ultimately ,  OOPLs  will  have  to  be  designed 
which  can  search  inheritance  graphs  for  name 
conflicts,  and  make  decisions  based  upon 
semantic  properties  of  the  affected  methods  and 
inheriting  subclasses. 

B.  COMPOSITION  AND  INHERITANCE 

A  fundamental  task  of  OOD  is  to  determine  the  behavior  and 
structure  of  objects  (as  abstracted  into  a  class) .  Often, 
designers  must  consider  whether  structures  and  behaviors 
should  be  inherited  or  realized  through  composition^^.  This 
task  inevitably  requires  investigating  the  nature  of  the 
relationships  which  exist  between  objects.  At  first  glance, 
the  decision  appears  to  be  a  simple  distin'^tion  between  'kind- 
of'  and  'part-of'  relationships.  However  in  many  situations 
the  complexity  of  object  relationships  vitiates  quick 
determination  of  appropriate  relationships,  and  therefore 
complicates  inheritance/composition  choices. 

The  real  difficulty  in  dealing  with  composite  objects  is 
that  the  00  design  process  focuses  on  classes  and  class 
hierarchies  in  a  manner  which  emphasizes  the  independence  of 
the  abstractions  being  described.  This  conceptual  approach 
does  not  directly  lend  itself  to  the  analysis  of  composition 
relationships  which  can  exist  between  objects  of  classes  in 
different  hierarchies.  Designers  must  therefore  carefully 
detail  the  entire  nexus  of  object  interconnections  that 
formulate  a  composite  object.  A  critical  matter  in  this 

^■^Recall  that  inheritance  reflects  relationships  between 
classe.s  while  composition  reflect  s  r‘=>lat  i'cislrij's  b^twoon 
objects . 
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regard  is  determining  whether  an  object's  behavior  is  modified 
when  it  forms  'part-of'  a  higher  level  object  (i.e.,  has  a 
role  to  play  in  some  form  of  collective  behavior) ,  Designers 
must  address  where  these  constraints  are  to  be  effected,  and 
what  policy  to  pursue  if  an  object  has  more  than  one  role  to 
play  (i.e.,  is  'part-of'  more  than  one  object) . 

This  section  reviews  composition,  advances  criteria  for 
recognizing  composition  relationships,  draws  out  the 
implications  of  using  composition  versus  inheritance, 
illustrates  inheritance/composition  tradeoffs  by  presenting 
solutions  to  a  simple  design  problem  using  three  different 
OOPLs,  and  considers  to  what  degree  composite  objects  should 
parallel  the  details  of  real-world  objects. 

1 .  Composition  Reviewed 

Chapter  Il/Section  D  introduced  the  idea  of 
composition,  noting  several  properties  of  composition 
relationships.  The  concept  is  further  analyzed  in  this 
subsection/  particular  attention  is  directed  to  subtleties 
which  complicate  the  design  of  composite  objects. 

Composition  "...is  a  tightly  coupled  form  of 
association^^  with  some  extra  semantics."  (Rumbaugh,  1991,  pg. 
37)  Rumbaugh  (1991)  discusses  several  properties  of 
composition  which  distinguish  it  as  a  specialized  form  of 

^^Association  is  an  abstraction  used  to  or'T'up  objects  from 
several  independent  classes.  (Elmasri  and  Navathe,  1989) 


association:  (1)  the  relationship  is  transit  ive^^;  (2)  the 

relationship  is  antisyminetric^®;  and,  (3)  properties  (state 
values  and  operations)  of  the  whole  can  propagate  to  the 
part^  ■  . 

That  properties  propagate  raises  several  interesting 
issues.  First,  the  form  of  interconnectedness  induced  by 
composition  requires  analyzing  the  existential  dependency  of 
contained  objects.  Specifically,  should  an  object  which  is 
part  of  another  object  manifest  a  separate  identity?  This  has 
implications  for  creation  and  destruction  operations.  It  also 
portends  the  possibility  of  conflicting  interobject 
interactions.  Technically,  the  problem  can  be  viewed  as  one 
in  which  the  variables  which  make  up  an  object  are  themselves 
objects^^,  or  are  pointers  to  objects^®.  (Nelson,  1990)  Not 
surprisingly,  pointer  referencing  also  allows  contained 
objects  to  be  shared  by  more  than  one  containing  object. 
Second,  subobjects  and  dependent  objects  most  likely  will  have 


^^For  example,  A  is  part  of  B,  and  B  is  part  of  C  implies 
that  A  is  part  of  C. 

^^A  is  part  of  B  implies  that  B  is  not  part  of  A. 

^®An  example  would  be  that  the  speed  of  an  aircraft 
propagates  to  the  parts  which  compose  the  aircraft  -  the 
wheels,  engines,  wings,  etc. 

^^Nelson  terms  these  "dependent  objects."  (Nelson,  1990, 
pg .  5)  Dependent  objects  do  not  exist  apart  from  the  obiects 
they  are  a  part  of. 

^®Nelson  terms  these  "subobjects."  (Nelson,  1990,  pcj . 
5)  Subobjects  do  exist  apart  from  the  obiects  they  aie  part 
of  . 
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some  properties  in  common  with  the  object  of  which  they  are  a 
part‘d.  This  follows  naturally  from  the  idea  of  property 
propagation.  However,  as  suggested  above,  subobjects  may  be 
'part-of"  more  than  one  object  -  creating  a  requirement  to 
insulate  subobjects  against  potentially  conflicting  state 
changes.  Third,  transitivity  implies  that  these 

considerations  flow  through  to  all  objects  at  whatever  level 
in  a  composition  hierarchy^*^ .  Complex  determinations  must  be 
made  as  to  what  level  properties  propagate  to.  Finally, 
antisymmetry  implies  that  properties  do  not  necessarily 
propagate  to  higher  levels  in  a  composition  hierarchy. 

Another  facet  of  composition  requiring  attention  is 

the  cardinality  relationship  between  containing  objects  and 

sub/dependent  objects.  Possibilities  include  the  following: 

Aggregation  can  be  fixed,  variable,  or  recursive.  A  fixed 
aggregate  has  a  fixed  structure;  the  number  and  types  of 
subparts  are  predefined'^ .  A  variable  aggregate  has  a  finite 
number  of  levels,  but  the  number  of  parts  may  var}r‘ .  A 


^’This  possibility  reflects  a  design  consideration  - 
should  propagated  properties  be  maintained  by  contained 
objects,  or  can  these  properties  be  assumed  to  be  maintained 
by  the  containing  object?  Solutions  to  this  question  may  be 
influenced  by  whether  or  not  contained  objects  exist 
independent  of  the  containing  object. 

composition  hierarchy  can  be  conceived  of  as  a  tree 
depicting  composition  relationships.  Such  a  hierarchy  starts 
with  the  highest  level  object,  and  moves  downward  to 
successively  more  granular  levels  of  detail. 

^^For  example,  a  golf  club  always  has  on“  clubhead,  one 
shaft,  and  one  grip. 

^^For  example,  an  academic  course  may  consist  of  a  single 
profes  sor  and  severaJ  students.  However,  theie  may  be  a 
variable  number  of  students  per  course  (i.e.,  a  one-to-many 
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recursive  aggregate  contains,  directly  or  indirectly,  an 
instance  of  the  same  kind  of  aggregate ;  the  number  of 
potential  levels  is  unlimited^- .  (Rumbaugh,  1991,  pg.  59) 

Fixed  aggregates  are  the  easiest  to  understand  and  design. 

Variable  aggregates,  however,  pose  interesting  problems  for 

reusability.  How  does  one  design  a  class  for  composite 

objects  such  that  objects  can  be  instantiated  with  variable 

numbers  of  parts?  Must  each  variation  be  modeled  by  a 

distinct  class  (using  inheritance) ?  This  problem  will  be 

investigated  in  Subsection  4. 

Finally,  a  distinction  is  sometimes  drawn  between  objects 
that  are  composed  of  other  objects  (a  car)  and  objects  that 
contain  other  objects  (an  array  of  integers) .  (Wirfs-Brock, 
Wilkerson,  and  Wiener,  1990)  Though  both  relationships  can  be 
modeled  as  composition,  containment  is  a  much  looser  form  of 
association.  It  is  often  the  case  that  a  container  does  not 
need  to  interact  with  the  elements  it  holds.  In  other  cases, 
interactions  do  occur^^.  Frequently,  containment  relationships 
involve  a  design  choice  between  employing  composite  objects  or 
instantiations  of  parameterized  classes  (see  Chapter 


relationship  prevails) . 

^^For  example,  a  computer  program  may  consist  of  blocks 
containing  compound  statements  which,  in  turn,  contain  other 
blocks.  (Rumbaugh,  1991)  Recursive  composition  should  be 
avoided  in  most  cases  as  there  is  the  potential  for  an 
infinite  recursion  in  which  an  object  calls  upon  itself  to 
formulate  its  definition. 

^*For  example,  a  hash  table  may  need  to  ask  an  element  for 
its  hash  code  before  adding  the  element  to  th<^  table.  (Wirfs- 
Brock,  Wilkerson,  and  Wiener,  1990) 
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Il/Section  B)  .  Containers  that  do  not  interact  with  their 
parts  are  probably  best  modeled  using  parameterized  classes. 
This  clearly  identifies  the  limited  behavioral  connections 
between  the  container  and  the  objects  it  holds. 

2 .  Recognizing  Composition 

Several  keys  to  composition  have  already  been 
discussed:  (1)  'part-of'  relationships;  (2)  propagation  of 
properties/operations;  (3)  cardinality  considerations;  and, 
(4)  interobject  behavioral  const raint .  Other  facts  of  a 
problem  situation  may  also  suggest  that  composition  fits  a 
particular  object  to  object  relationship.  These  include  the 
following:  (1)  collective  instantiation  and  destruction;  (2) 
delegation  of  responsibilities  from  the  whole  to  parts; 
(Wirf s-Brock,  Wilkerson,  and  Wiener,  1990)  and,  (3)  service 
unity^® . 

3 .  Composition  or  Inheritance? 

Though  individual  facts  may  indicate  that  composition 
is  the  appropriate  design  choice,  the  possibility  always 
exists  for  modeling  such  relationships  using  inheritance^^.  In 


^^Composite  objects  "...describe  for  instantiation  a 
richly  connected  set  of  objects. ..."  (Stefik  and  Bobrow,  1986, 
pg.  58) 

^*This  rather  vague  notion  marks  the  fact  that  parts  do 
not  act  independently,  but  rather  are  controlled  by  the 
unifying  purpose  of  the  whole  object.  This  would  serve  to 
distinguish,  for  instance,  a  clock  and  a  radio  which  happen  to 
be  collocated,  from  a  clock-radio. 

^'In  particular,  multiple  inheritance  can  V'o  used  as  an 
alternative  to  composition. 
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many  situations,  it  is  not  clear  whether  composition  or 
inheritance  should  be  used  (the  design  problem  considered  in 
the  following  subsection  is  an  example) .  Hence,  it  is  worth 
considering  in  what  respects  the  consequences  of  selecting  one 
over  the  other  differ. 

Inheritance  is  a  class  relationship,  whereas 
composition  is  an  instance  association;  differences  in  the 
nature  and  mechanics  of  the  two  relationships  start  from  this 
fundamental  distinction^®.  First,  the  hierarchical  structure 
which  serves  to  define  a  class  through  inheritance  establishes 
the  identity  of  a  single  object.  Composition,  on  the  other 
hand,  involves  a  relationship  between  ol  lects  with  separate 
identities®® . 

Second,  composition  strictly  limits  visibility  on  the 
part  of  the  containing  object  to  the  external  interfaces  of 
its  parts.  Inheritance  allows  a  finer  degree  of  visibility 
which  generally  entails  greater  accessibility  through  the 
internal  interface. 

Third,  inherited  behavior  is  visible  to  other  objects 
to  the  extent  that  it  is  included  in  the  external  interface. 
The  behavior  of  objects  serving  as  parts,  on  the  other  hand, 
is  not  visible  to  other  objects  -  the  containing  object 


®®Composit  ion  can  be  thought  of  as  a  form  of  part 
inheritance  while  inheritance  can  be  viewed  as  behavioral 
inheritance.  (Nelson,  1990) 

®®This  holds  regardless  of  whether  the  part  is  a  dependent 
object  or  a  subobject. 
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mediates  any  such  interactions^'’. 


Fourth,  "behavior  can  be  easier  to  reuse  as  a 
component  than  by  inheriting  it."  (Johnson  and  Foote,  1991, 
pg.  124)  As  an  example,  it  is  easier  to  add  an  extra 
scrollbar  to  a  window  as  a  component,  than  it  is  to  multiply 
inherit  scrollbars.  (Johnson  and  Foote,  1991)  The  idea  is 
that  inheritance  used  in  this  manner  may  require  undesirable 
changes  to  the  behavior  established  by  ancestor  classes. 

Fifth,  as  noted  in  the  previous  section,  inheritance 
potentially  exposes  information  hiding  to  compromise. 
Composition  does  increase  the  coupling  between  objects; 
nevertheless,  information  hiding  is  not  violated  since  all 
interactions  are  managed  through  the  respective  external 
interfaces . 

Finally,  specialization  was  previously  identified  as 
the  principle  strategy  for  structuring  class  hierarchies  (see 
Chapter  Il/Section  C)  .  Hence,  an  appropriate  question  to  as)c 
when  contemplating  inheritance/composition  choices  is  whether 
or  not  a  resulting  subclass  can  be  said  to  be  a  specialization 
of  the  class  (es)  from  which  it  inherits.  For  example,  "it  is 
not  valid  to  define  a  class  Car  that  inherits  from  Body, 
Frame,  Wheels,  and  similar  classes,  since  a  car  is  not  a 
wheel."  (Nierstrasz,  1989,  pg.  8)  A  different  perspective  on 
specialization  is  to  consider  the  substitution  possibilities 


^°This  distinction  is  reduced  to  the  extent  that  an  OOFL 
permits  manipulations  by  pointer  operations. 
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discussed  in  Chapter  II.  Inheritance  should  not  be  used  if 
substituting  a  subclass  object  for  a  superclass  object  does 
not  satisfy  applicable  compatibility  requirements  (for 
example,  a  car  cannot  be  substituted  for  a  wheel  in  any 
meaningful  way) . 

4  .  The  ClocJc_Radio  Problem 

It  is  instructive  to  underline  the  ramifications  of 
selecting  composition  or  inheritance  by  investigating  the 
solution  to  a  sample  design  problem.  This  section  considers 
designs  for  a  clock_radio  in  three  different  OOPLs:  C++, 
Smalltalk,  and  CLOS .  Separate  solutions  for  each  OOPL,  one 
using  inheritance  and  the  other  using  composition,  are 
illustrated  and  compared. 

Although  a  major  theme  of  this  thesis  is  the  advocacy 
of  OOA/OOD  practices  which  enhance  the  entire  OOP  process, 
independent  of  any  particular  OOPL,  it  must  be  conceded  that 
at  this  point  in  the  evolution  of  OOPLs  language  selection 
does  impact  design  opportunities.  Hence,  the  three  OOPLs  are 
also  used  to  illustrate  language  dependent  differences  between 
composition  and  inheritance. 

a .  Problem  Statement 

The  clock_radio  is  a  common  household  device  which 
consists  of  a  clock  and  a  radio.  It  manifests  many  of  the 
properties  listed  above  for  recognizing  composition:  (1)  the 
clock  and  the  radio  are  parts  of  a  clock_radio;  (2)  properties 
such  as  location  and  power  propagate  from  the  whole  to  the 
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parts;  (3)  a  clock-radio  could  conceivably  contain  more  than 
one  clock,  or  more  than  one  radio;  and,  (4)  behavioral 
constraints  not  ordinarily  associated  with  separate  clocks  and 
radios  are  possible  (for  example,  a  clock  controlled  timer  can 
turn  the  radio  off) .  Figure  2  displays  the  responsibilities 
that  rudimentary  OOA  might  reveal  as  germane  to  a 
clock_radio.  State  information  represents  knowledge  that  a 
clock_radio  maintains  about  itself.  Services  define  the 
behavior  of  a  clock  radio.  The  list  is  obviously  not 
complete,  but  for  present  purposes  can  be  accepted  as  a 
standard  upon  which  permutations  may  be  structured.  Note  that 
Figure  2  is  not  a  class  definition  in  any  OOPL,  but  rather  a 
listing  of  behaviors  and  state  information.  Hence, 
distinctions  such  as  instance  and  class  variables  are  not 
required . 


State  information 
present_location 
power_on 

Services 
set_time 
set_clock_alarm 
set_radio_alarm 
play_am 
play  fm 


r adi o_a 1 arm_t ime 
clock  alarm  time 


volume_increase 
volume_decrease 
select_channel 
radio  on 


Figure  2:  Clock_Radio  Responsibilities 


In  the  subsections  which  follow  analysis  will 


focus  on  three  classes:  electric_clock,  radio,  and 

clock_radio.  To  simplify  discussion,  the  electric  clock  and 
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radio  classes  are  not  placed  into  hierarchies  (i.e.,  a 
detailed  design  in  which  suitable  variables  and  methods  are 
elevated  to  abstract  classes  is  not  performed) .  Figure  3 
illustrates  the  inheritance  class  relationships,  and  Figure  4 
shows  the  composition  object  relationships  which  will  be 
modeled. 

Class  electric  clock  Class  Radio 


Class  clock  radio 

Figure  3:  Inheritance  Class  Relationships 


Object  Glock_radio 

object  electric__clock 
object  radio 

Figure  4:  Composition  Object  Relationships 

The  implementations  contained  in  Appendices  A,  B, 
and  C  are  not  intended  to  demonstrate  a  comprehensive,  usable 
solution.  In  particular,  error  handling  is  not  provided.  For 
the  dynamically  typed  languages  (Smalltalk  and  CLOS) ,  no 
effort  was  made  to  enforce  type  checking.  Casual  observation 
will  also  reveal  that  instance  variables  are  directly  accessed 
in  most  of  the  implementations.  This  was  done  to  reduce  and 
simplify  the  code. 
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Jb. 


C++  Solution 


C++  is  a  hybrid  OOPL,  erected  on  the  foundation  of 
the  C  programming  language.  The  principal  building  blocks 
include  objects,  message  passing,  classes,  and  inheritance 
hierarchies.  C++  is  a  strongly  typed  language  in  which 
classes  implement  abstract  data  types.  The  language  does 
provide  for  virtual  classes  and  for  public,  protected,  private 
visibility  declarations.  Multiple  inheritance  hierarchies  can 
also  be  built. 

Appendix  A  contains  the  C++  solution  to  the 
clock_radio  problem.  The  code  successfully  compiled  and 
tested  on  a  Borland  Turbo  C++  compiler.  (Borland 
International,  1990)  Section  A  contains  the  declarations  for 
the  various  classes  in  the  problem,  including  classes  for 
types  time  and  position.  Following  the  class  name  is  a  list 
of  type  declarations  (for  example,  x_y_posit)  and  variable 
names  (for  example,  radio_locat ion)  .  Due  to  the  absence  of  any 
visibility  declaration,  the  default  visibility  for  the 
variables  is  private.  Note  that  variables  such  as  size  and 
color  could  also  be  included.  These  were  omitted  since 
location  and  power  already  serve  the  purpose  of  demonstrating 
variables  whose  value  propagate  from  the  whole. 

All  methods  are  given  public  visibility; 
consequently,  they  belong  to  both  the  external  and  the 
internal  interfaces.  'Void'  indicates  that  a  method  does  not 
return  a  value.  Finally,  a  method  with  th'=  .same  name  as  the 
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class  name  is  a  constructor.  Constructors  set  aside  space  in 
memory  when  an  object  instance  is  created  and  can  be  used  for 
initializing  instance  variables^^.  Similarly,  a  method  with 
the  class  name  and  a  tilde  (~)  prefixed  is  a  destructor.  An 
example  of  a  destructor  is  given  in  electric_clock  class. 
Destructors,  which  can  only  be  called  by  the  compiler,  are 
used  to  undo  side  effects  such  as  changes  to  global  variables. 
(Eckel,  1989)  Generally,  programmer-defined  destructors  are 
not  included;  instead,  a  default  destructor  supplied  by  the 
compiler  is  used.  (Eckel,  1989) 

(1)  Inheritance.  Class  clock_radio  in  Appendix 
A/Section  A  illustrates  the  design  of  clock_radio  class 
using  multiple  inheritance.  The  public  declarations  in  the 
first  line  indicate  that  the  internal  and  external  interfaces 
of  superclasses  are  inherited  as  designed  (variable/method 
visibilities  remain  unchanged) .  Sections  B  through  G  provide 
implementations  of  the  methods  for  the  respective  classes. 
Observe  that  a  more  fully  developed  clock  design  would  access 
operating  system  clock  functions  to  provide  actual  time 
behavior.  This  was  not  done  to  simplify  the  problem.  Note  the 
efficiency  by  which  the  behavior  of  the  class  is  managed 
through  multiple  inheritance.  Simple  extension  is  used  to 
complete  the  behavior  of  the  class,  and  reusability  is 
exploited . 

*^In  this  case,  it  is  assumed  that  th“  constructf^r 
initializes  the  electric-clock  to  a  powered  state  and  the 
alarm  to  off  (i.e.,  power_on  ;=  True,  and  alarm  on  :=  False) . 
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Several  other  features  merit  attention.  First, 
clock  radio  is  a  subtype  of  both  an  electric  clock  and  a 
radio,  and  can  consequently  substitute  for  either  one.  This 
follows  from  the  identification  of  class  and  type  hierarchies 
enforced  by  C-^+. 

Second,  although  not  present  in  this  design,  it  is 
conceivable  that  name  conflicts  could  exist  for  the  location 
variable  and  the  po;;er  method.  C++  resolves  this  through 
resolution  operators.  Name  conflicts  must  always  be 
considered  when  using  inheritance.  Unless  the  design 
strategies  noted  in  the  previous  section  are  followed, 
preventing  and  resolving  name  conflicts  inevitably  requires 
knowledge  about  superclass  details. 

Third,  while  Ci+  allows  a  class  to  be  inherited 
indirectly  more  than  once,  a  given  superclass  can  only  be 
directly  inherited  once.  This  poses  cardinality  problems. 
Essentially,  a  clock  radio  class  based  on  inheritance  must  be 
redesigned  each  time  a  different  combination  of  clocks  or 
radios  is  desired. 

Finally,  constructor  and  destructor  methods  cannot 
be  inherited.  (Atkinson  and  Atkinson,  1991)  Unless  compiler 
supplied  default  constructors  and  destructors  are  preferred, 
subclass  methods  must  explicitly  account  for  ancestor 
constructors  and  destructors.  This  fact  assumes  importance 
during  hierarchy  desian  as  it  can  impact  object  initialization 
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and  free  memory  managements^.  (Atkinson  and  Atkinson,  1991) 

(2)  Composition.  The  composite_clock_radio  class 
in  Appendix  A/Section  A  uses  composition  to  reuse 
electric  clock  and  radio  behavior.  Several  features  alluded  to 
above  are  immediately  apparent.  First,  the  external  interface 
of  the  clock_radio  is  the  only  conduit  to  contained  objects 
for  objects  using  a  clock_radio.  Hence,  greater  design  effort 
is  required  to  engineer  the  desired  behavior.  Note  that  the 
external  interface  to  the  composite_clock_radio  class 
essentially  duplicates  the  electric_clock  and  radio 
interfaces.  Although  this  promotes  information  hiding,  it 
also  translates  to  a  degree  of  inefficient  CPU  use  since  it 
amounts  to  providing  methods  whose  sole  purpose  is  to  function 
as  a  protective  layer  (i.e.,  doubles  function  call 
processing) . 

Second,  name  conflicts  are  not  a  problem.  If  all 
interactions  are  forced  through  the  external  interfaces  of  the 
electric_clock  and  the  radio  respectively,  name  conflicts 
cannot  occur. 

Third,  the  facility  with  which  extra  radios  or 
electric_clocks  could  be  added  as  constituent  parts  is 
evident:  simply  declare  new  variables  of  the  required  types. 
Nonetheless,  the  implementation  of  clock_radio  methods  which 
control  interactions  among  the  various  parts  would  have  to  be 

^^It  has  been  recommended  that  virtual  constructors  and 
destructors  be  declared  in  superclasses  ease  tbe  design 
burden  on  subclasses.  (Atkinson  and  Atkinson,  1991) 
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modified  to  account  for  the  new  structure  of  the  entire 


object.  The  same  logical  changes  have  to  be  made  when  using 
inheritance.  In  this  respect  there  is  no  advantage  to  using 
composition.  However,  it  still  remains  much  easier  to  create 
multiple  parts  using  composition. 

Fourth,  as  is  the  case  with  inheritance, 
constructors  and  destructors  must  be  specifically  accounted 
for.  This  can  be  done  comparatively  easily  using 
initialization  lists.  (Atkinson  and  Atkinson,  1991)  In 
distinction  to  inheritance,  deciding  which 
constructors /destructors  to  include  is  simple:  those  of 
contained  objects  (this  assumes  no  inheritance) .  Multiple 
inheritance,  on  the  other  hand,  can  produce  complicated 
scenarios  in  which  sequencing  of  construction/destruction  is 
important.  Composition  only  requires  that  contained  objects 
be  created  prior  to  the  containing  object. 

Fifth,  a  strategy  needs  to  be  adopted  for  handling 
properties  which  propagate.  Both  electric_clock  and  radio 
objects  contain  instance  variables  for  location.  Designers 
must  decide  whether  or  not  to  include  a  location  instance 
variable  for  the  clock_radio,  and  whether  or  not  to  propagate 
location  assignments  to  both  the  electric_clock  and  the  radio 
parts.  Property  propagation  creates  familiar  data  update 
problems  (ensuring  consistent  information  is  maintained) ,  and 
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Notice  also  that 


constitutes  unnecessary  data  duplication^', 
property  propagation  also  implies  some  knowledge  about  the 
details  of  part  objects^^.  In  this  solution,  responsibility 
for  maintaining  location  and  power  information  is  retained  by 
the  clock_radio.  Changes  are  propagated  to  its  respective 
parts.  Note,  however,  that  this  responsibility  is  directly 
inherited  when  inheritance  is  used.  Consequently,  a  location 
instance  variable  was  not  created  for  clock_radios  formed  by 
inheritance.  This  appears  to  be  a  situation  in  which  it  would 
be  useful  to  design  electric_clock  or  radio  subclasses  which 
exclude  the  location  instance  variable.  However,  all  the 
methods  in  the  affected  class  would  have  to  be  searched  to 
eliminate  direct  references  to  this  variable  or  calls  to 
accessor  methods. 

Finally,  a  clock_radio  is  no  longer  a  subtype  for 
an  electric_clock  or  a  radio.  Hence,  substituting  a 
clock  radio  for  either  of  its  two  parts  would  generate  an 


significant  difference  should  be  noted  between 
inheritance  and  composition.  In  languages  which  do  not 
provide  visibility  control  mechanisms  like  those  found  in  C++, 
the  external  interface  includes  inherited  methods.  Hence, 
messages  can  be  sent  to  descendent  objects  that  invoke 
inherited  methods  which  return  state  information  relating  to 
propagated  properties  from  instance  variables  declared  in 
ancestor  classes.  Designers  must  ensure  that  all  such  state 
information  is  current  and  consistent  since  such  calls  can  not 
be  precluded  in  these  kinds  of  languages.  Smalltalk  is  an 
example  of  one  such  OOFL. 

**A11  of  these  considerations  also  apply  to  multiple 
inheritance  in  which  more  than  one  superclass  maintains  the 
same  state  information. 
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error  message  at  compile  time 


c.  Smalltalk  Solution 

Smalltalk^^  is  a  dynamically  typed  OOPL  featuring 
objects,  classes,  metaclasses,  and  single  inheritance^®. 
Messages  can  be  sent  to  instances  (instance  methods)  ,  or  to 
classes  (class  methods) Class  definitions  include  instance 
variables  and  class  variables.  A  singular  quality  of 
SmalltaDt  is  its  comprehensive  environment:  programming  and 
design  are  all  accomplished  within  the  confines  of  the 
Smalltalk  system  of  disk  and  hierarchy  browsers  employing 
extensive  windowing  and  menu  controls. 

Another  useful  feature  of  the  Smalltalk 
environment  is  its  library  of  predefined  classes.  All  classes 
(predefined  and  user  defined)  comprise  one  large  hierarchy 
descended  from  the  root  class  Object.  New  classes  are  defined 
by  filling  in  the  appropriate  information  in  system  supplied 
templates.  New  classes  must  be  descended  from  a  superclass  in 
the  hierarchy. 


^^Several  variants  of  the  Smalltalk  language  are 
commercially  available.  These  dialects  manifest  widely 
varying  capabilities.  The  present  discussion  draws  upon 
Digitalk's  Smalltalk/V286 .  (Smalltalk/V286,  1988) 

*®Other  versions  of  Smalltalk  do  provide  for  multiple 
inheritance.  (Stefik  and  Bobrow,  1986)  However,  the  use  of 
multiple  inheritance  in  these  versions  "  .  .  .  is  not  used  much  or 
institutionalized."  (Stefik  and  Bobrow,  1986,  pg .  49) 

^^Classes  are  treated  as  objects  in  Smalltalk;  hence,  the 
need  for  metaclasses. 


(1)  Inheritance.  Though  the  requirement  to  place 
new  classes  into  the  inheritance  hierarchy  facilitates  shaping 
a  common  protocol,  the  absence  of  stand-alone  classes  reduces 
the  flexibility  with  which  designers  can  construct  classes  - 
it  slows  development  to  the  extent  that  designers  must 
consider  potentially  lengthy  inheritance  chains.  Visibility 
of  variables  to  other  objects  is  limited  to  accessor  methods 
provided  by  the  class.  All  variables  and  methods  are 
inherited;  subclasses  can  add  new  variables  or  methods,  and 
can  override  superclass  methods. 

Appendix  B/Section  A  displays  completed  templates 
for  the  various  classes  in  the  clock_rad  j  problem.  Sections 
B  through  G  display  method  implemtations .  The  code 
successfully  interpreted  and  tested  on  Digitalk' s 
Smalltalk/V286  interpreter.  The  electric_clock  class  inherits 
from  the  radio  class,  while  the  radio  class  is  assumed  to  have 
the  electric_device  class  (not  depicted)  as  its  superclass. 
Variables  are  defined  without  type  declarations  and  the  class 
interface  is  not  included  in  the  template.  Methods  are 
defined  by  selecting  the  new  method  menu  option;  hence,  a 
method  interface  and  its  implementation  are  defined 
simultaneously.  Each  class  has  the  same  methods  as  those 
previously  identified  for  the  corresponding  C++  class. 

Given  that  Smalltalk/V286  allows  only  single 
inheritance,  one  of  the  two  superclasses  must  be  inherited 
from  the  other  in  order  to  replace  multiple  inheritance.  This 
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is  not  a  desirable  state  because  instances  of  the  inheriting 
class  must  exhibit  behavior  of  the  superclass;  hence,  for 
example,  a  pure  radio  could  not  be  instantiated  should  the 
radio  class  inherit  from  the  electric_clock  class. 
Additionally,  such  inheritance  establishes  hierarchies  that  do 
not  truly  reflect  any  sort  of  specialization:  an 
electric_clock  is  not  a  specialization  of  a  radio.  Designers 
should  be  very  deliberate  and  consistent  in  selecting  criteria 
for  structuring  the  single  Smalltalk  hierarchy.  Problems 
arise  when  the  same  class  serves  multiple  roles:  template  for 
inheritance,  part  object  template,  and  user  object  template^®. 

Immediately,  all  name  conflict  problems  previously 
discussed  reappear.  Note  that  Smalltalk  treats  conflicting 
instance  variable  names  as  an  error.  Note  also  that  a 
clock_radio  can  be  safely  substituted  for  an  clectric_clock  or 
a  radio  using  this  form  of  inheritance.  Similarly,  an 
electric_clock  can  be  safely  substituted  for  a  radio  since  it 
inherits  behavior  from  the  radio  class.  The  latter 
possibility  is  not  desirable  for  reasons  presented  earlier. 

Inherited  instance  variables  are  accessible  by 
name  in  Smalltalk.  This  poses  a  problem  for  designers  of 
inherited  classes  such  as  clock  radio.  A  clock  radio 


^®A  user  object  (my  term)  is  a  semantic  notion  describing 
objects  which  interact  with  other  objects  through  respective 
external  interfaces  while  maintaining  independent  identities 
that  do  not  involve  composition.  The  idea  is  drawn  from  Booch 
who  distinguishes  containino  relationships  from  usina 
relationships.  (Booch,  1991) 
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designed  through  inheritance  is  conceived  of  as  a  single, 
unified  object.  Given  that  Smalltalk  is  a  dynamically  typed 
language,  a  designer  must  have  knowledge  of  superclass  method 
implementations  in  order  to  avoid  inconsistent  variable  typing 
(especially  if  overriding  inherited  variables  or  methods) . 
Conflicts  can  be  avoided  by  using  only  inherited  methods  to 
access/modify  inherited  variables.  However,  this  then 
requires  that  ancestor  classes  be  designed  to  account  for 
descendant  class  (actual  and  potential)  requirements^'.  This 
sort  of  design  thinking  is  adequate  for  specialization 
hierarchies,  but  is  exceedingly  difficult  for  hierarchies 
replacing  multiple  inheritance. 

As  is  the  case  with  C++,  inheritance  in  Smalltalk 
is  entirely  inadequate  for  designing  clock_radios  with 
multiple  clocks  or  radios.  The  limitation  is  made  apparent  by 
the  fact  that  only  single  inheritance  is  allowed. 

Finally,  designers  should  design  constructor  and 
initializer  class  methods  which  account  for  ancestor  classes. 
The  safe  approach  is  to  design  initializer  methods  which  issue 
aupmr  calls  to  the  superclass  initializer;  thereby,  avoiding 
any  typing  errors.  Smalltalk  automatically  supports  garbage 
collection;  hence,  destructors  are  not  required. 

(2)  Composition.  Appendix  B/Section  A  displays 
the  Smalltalk  definition  for  a  composite  clock  radio  class; 

‘"That  is,  an  ancestor  class  must  provide  descendent 
classes  with  all  the  methods  they  requir<=>  access /modi  f  y 
inherited  variables. 


116 


instance  variables  for  a  clock  and  a  radio  are  defined.  All 


interactions  with  the  objects  these  variables  point  to  are 
managed  through  the  objects'  interfaces.  Clearly,  this 
approach  to  designing  a  clock_radio  is  much  cleaner  than  a 
solution  based  upon  ersatz  multiple  inheritance. 

Again,  the  template  in  Section  A  illustrates  that 
only  variable  names  have  been  defined.  It  has  been  argued 
that  the  absence  of  a  type-system  in  Smalltalk  renders  it 
impossible  for  a  compiler  to  optimize  Smalltalk  code. 
(Johnson,  1988)  The  thought  can  be  taken  a  step  further  by 
asserting  that  the  absence  of  a  type-system  also  severely 
undermines  the  type  continuity  that  should  prevail  among  the 
parts  of  an  object.  Designers  must  assume  responsibility  for 
ensuring  that  conceptually  inappropriate  type  assignments  or 
method  selections  do  not  occur  at  run-time.  This  is,  of 
course,  a  difficult  task  at  best.  However,  in  the  absence  of 
a  type-system  that  can  be  used  by  a  compiler^®,  designers 
should  enforce  type  continuity  of  parts  through  the  following 
steps:  (1)  clock_radio  object  creation  should  create  and 
initialize  parts  according  to  their  appropriate  class;  (2) 
state  changes  stored  in  instance  variables  should  be  effected 


^"Johnson  describes  an  effort  at  introducing  a  type-system 
to  Smalltalk  that  is  "...type-safe,  handles  polymorphic 
procedures  and  parameterized  types,  and  can  be  used  by  an 
optimizing  compiler."  (Johnson,  1988,  pg .  317) 
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by  accessor  methods  which  perform  type  checking^\*  and,  (3) 
messages  sent  to  a  part  are  type  correct  for  the  part,  or  for 
any  ancestors  of  a  part^^. 

Multiple  clocks  or  radios  can  be  added  by  defining 
specialized  subclasses  of  class  clock_radio.  Clock_radio 
class  methods  which  organize  part  behavior  will  need  to  be 
extended  to  accommodate  new  structures . 
d.  CLOS  Solution 

CLOS  is  a  hybrid  OOPL  built  upon  the  Common  Lisp 
programming  language.  (Koschmann,  1990)  It  features  objects, 
classes,  generic  functions,  and  methods.  Classes  consist  of 
local  and  shared  slots  (instance  and  class  variables) . 
Programmers  attach  methods  to  generic  functions  through  method 
definition*^,  and  users  invoke  methods  by  calling  the 


*^Most  Smalltalk  instance  variables  contain  pointers 
referring  to  objects.  (Smalltalk/V286,  1988)  Some  instance 
variables  contain  8  bit  bytes  representing  elementary  data 
values.  (Smalltalk/V286,  1988)  Instance  variable  types  can 
easily  be  changed  by  assigning  pointers  to  different  objects 
(i.e.,  avoid  aliasing). 

*^Johnson  states  that  "a  message-send  is  type-correct  if 
it  is  type-correct  for  each  possible  object  type  of  the 
receiver."  (Johnson,  1988,  pg.  318)  He  describes  the  process 
of  unification  which  establishes  that  a  "procedure  call  is 
type-correct  if  there  is  some  assignment  of  types  to  type 
variables  (of  the  method)  that  makes  the  types  of  the 
arguments  be  in  the  types  of  the  parameters;  the  return  type 
of  the  procedure  call  is  the  return  type  of  the  definition  of 
the  method  with  all  the  type  variables  replaced  by  the 
assignment  to  them."  (Johnson,  1988,  pg .  318) 

*^Generic  functions  constitute  the  interface  to  a  set  of 
methods.  Each  method  has  the  same  name  as  the  generic  function 
it  implements,  and  the  same  number  of  parameters.  The  generic 
dispatcher  selects  appropriate  methods  on  the  basis  of  type 
correspondence  between  message  arguments  and  method 
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appropriate  generic  function.  (Keene,  1989)  CLOS  provides  for 
multiple  inheritance  in  which  both  slots  and  methods  are 
inherited.  The  order  in  which  superclasses  are  listed  in  a 
class  definition  determines  precedence  for  handling  problems 
such  as  name  conflicts. 

CLOS  is  a  dynamically  typed  OOPL.  (Koschmann, 
1990)  Slots  can  be  typed  using  the  :typB  specifier.  However, 
many  commercially  available  CLOS  interpreters  do  not  enforce 
such  slot  typing.  (Keene,  1989) 

Appendix  C/Section  A  illustrates  the  definitions 
for  the  various  classes  in  the  clock_radio  problem.  Most  of 
the  slots  in  the  clock  radio  problem  are  assigned  default 
values  using  the  :  ini.  t  form  specifier.  This  prevents  any  slots 
from  being  unbound.  Sections  B  through  G  display  the  various 
method  implementations.  The  code  successfully  interpreted  and 
tested  using  an  Allegro  CL  interpreter  (Sun4  version) . 

(1)  Inheritance.  As  is  the  case  with  C++,  the  use 
of  multiple  inheritance  in  CLOS  to  build  a  clock_radio  class 
is  extremely  efficient.  A  clock_radio  class  can  be  descended 
from  these  two  superclasses  as  illustrated  by  the  clock  radio 
class  in  Section  A.  Again,  the  order  in  which  superclasses 
are  listed  determines  the  precedence  which  the  generic 


parameters.  In  the  absence  of  a  corresponding  generic 
function  for  a  meth'>d  definition  (defmethod)  ,  CLOS 
automatically  creates  the  generic  function  from  the  defmethod. 
The  CLOS  implementation  to  the  clock  radio  problem  assumes 
this  automatic  generic  function  building;  hence,  only 
defmethods  are  illustrated. 
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dispatcher  will  use  in  selecting  methods  for  generic  function 
calls.  Consequently,  this  form  of  precedence  exposes 
implementations  to  the  modification  errors  described  in 
Chapter  V/Section  A.  All  of  the  reservations  expressed  with 
respect  to  a  solution  using  inheritance  in  C++  also  apply  to 
a  solution  in  CLOS^^ .  Additionally,  dynamic  typing  presents 
the  same  problem  as  that  noted  for  Smalltalk  -  designers  need 
to  carefully  monitor  what  information  is  maintained  by  slots^^. 

(2)  Composition.  The  composite  clock_radio  class 
demonstates  composition  in  CLOS .  Essentially,  a  pointer  to 
the  desired  part  of  object  is  created  'using  the  built-in 
function  make -instance)  and  assigned  to  t  e  slot  variable.  As 
in  Smalltalk,  it  is  required  that  slots  be  created  and 
initialized  to  the  appropriate  types.  Observe  that  the  parts 
have  been  given  names  (for  example,  clock_one)  in  anticipation 
of  instances  which  have  multiple  parts.  This  is  not  good 
programming  style  in  that  users  must  maintain  information 
about  the  parts  of  an  object,  and  can  directly  refer  to  these 
parts.  Although  direct  naming  is  not  required  for  a 


®*CLOS  contains  a  variety  of  mechanisms  for  defining  and 
organizing  behavior:  mixins,  multi-methods,  before  methods, 
after  methods,  around  methods,  and  individual  methods. 
Developers  can  exercise  tight  control  over  method  structure, 
and  generic  dispatching.  However,  these  opportunities  often 
result  in  designs  which  are  highly  individualized,  tightly 
coupled,  and  susceptible  to  modification  errors. 

^•^CLOS  allows  slots  to  be  directly  accessed  using  the  setf 
function.  Interfaces  which  include  this  function  directly 
expose  data  structures  and  expose  slots  to  dynamic  type 
changes.  In  short,  designers  must  guarantee  that  slots  are  in 
fact  encapsulated. 
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clock  radio  consisting  of  only  one  clock  and  one  radio,  such 
naming  appears  to  be  unavoidable  for  this  kind  of  object  when 
larger  numbers  of  clocks  or  radios  are  included.  Clock  radio 
methods  can  be  defined  which  organize  the  interactions  between 
clock  one  and  radio  one.  As  before,  cardinality  can  be 
handled  by  defining  compos ite_clock_radio  subclasses  which  add 
new  parts  and  override  relevant  controller  methods  when 
necessary . 

An  important  difference  from  Smalltalk  is  that 
slots  can  be  directly  accessed/modified  using  the  built-in 
functions  slot-value  and  setf.  CLOS  provides  a  slot  specifier 
: accessor  which  automatically  creates  a  generic  function  for 
reading  and  writing  a  slot.  The  accessor  so  created  forms 
part  of  the  external  interface.  Nevertheless,  slots  are  not 
encapsulated  by  accessors.  CLOS  does  not  provide  any 
mechanisms  for  enforcing  the  notion  of  a  private  slot. 
Consequently,  composite  objects  in  CLOS  do  not  truly  form  an 
intermediate  layer  between  users  and  parts. 

5 .  Composition  Granularity 

Another  interesting  problem  with  respect  to 
composition  is  the  granularity  of  detail.  An  example  may 
serve  to  demonstrate  the  problem.  Each  clock  class  can  be 
designed  such  that  it  includes  one  electric  plug/cord 
combination.  Should  a  clockradio  consisting  of  multiple 
clocks  therefore  have  multiple  plugs  and  cords?  The  problem 
arises  from  the  fact  that  classes  can  serve  both  as  templates 
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for  composition  objects  and  as  templates  for  independent 
objects . 

The  solution  to  this  problem  lies  in  reconsidering  the 
fundamental  nature  and  purposes  of  OOA  and  OOD .  Guiding  00 
development  is  the  goal  of  specifying  and  organizing  the 
behavioral  properties  of  objects  in  the  application  domain. 
Although  aspects  of  physical  structure  enter  into  designs, 
these  only  occur  as  required  to  fulfill  behavioral 
requirements.  Similarly,  variables  are  iiicluded  only  as 
required  to  preserve  state  information.  The  primary  focus,  it 
should  be  reemphasized,  is  on  behavior.  Hence,  a  clock  is 
either  powered  or  it  is  not.  This  is  state  information  which 
should  be  included  in  a  design.  Though  a  plug/co form  a 
conduit  for  powering  a  clock,  they  really  do  not  have  any 
behavioral  responsibilities  that  other  objects  may  interact 
with,  and  they  cannot  be  associated  with  any  state 
preservation  duties.  Consequently,  a  design  for  a  clock  class 
should  not  include  variables  for  plugs  and  cords. 

The  clock_radio  problem  demonstrated,  however,  that 
different  classes  may  maintain  identical  state  informat.'' on . 
Hence,  multiple  instances  of  the  same  piece  of  information  are 
maintained  when  either  inheritance  or  composition  is  used.  As 
suggested  in  the  clock_radio  discussion,  this  is  an 
unavoidable  problem,  excepting  exclusion,  which  requires  some 
sort  of  data  consistency/duplication  policy  on  the  part  of 
designers . 
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The  same  problem  reappears  in  another  context  .  It  has 
previously  been  noted  that  both  in  the  context  of  system 
design  and  in  composition  design  properties/responsibilities 
are  delegated  to  constituent  elements.  It  is  not  improbable 
that  delegated  properties/responsibilities  may  not  be  needed 
in  new  design  problems;  thus,  reducing  reusability 
opportunities  and  forcing  considerable  redesign.  Expanding 
upon  the  notion  of  moving  common  behavior  upwards  in  class 
hierarchies  (see  Chapter  III),  classes  at  the  higher  levels  in 
a  hierarchy  should  provide  common  behaviors  in  the  most 
general  sense:  behavior  generalized  to  the  class  of  objects  as 
they  might  occur  in  any  application.  Hence,  a  clock  class 
would  provide  behavior  expected  of  any  clock.  Subclasses  can 
then  be  used  to  extend  behavior  to  suit  particular  system  or 
composite  object  requirements.  What  forms  a  generalized 
formulation  of  behavior  applicable  to  a  class  of  objects  is  a 
knowledge  problem  that  must  be  arrived  at  during  OOA. 
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VI .  CONCLUSIONS 


A.  SUGGESTIONS  FOR  FUTURE  RESEARCH 

1 .  Specialization 

Chapter  II  introduced  the  notion  of  specialization. 
This  concept  figures  importantly  in  controlling  the 
development  of  inheritance  hierarchies.  Nonetheless,  a 
formalized  definition  of  specialization  needs  to  be 
researched.  Such  a  definition  should  distinguish 
specialization  from  subtyping,  and  should  explore  the 
interrelationships  between  the  two  concepts  when  building 
inheritance  hierarchies. 

2 .  Reusability 

The  various  design  strategies  discussed  in  Chapter  III 
advanced  criteria  for  recognizing  and  organizing  the 
relationships  among  the  elements  of  a  problem.  These 
strategies  provided  criteria  for  the  explicit  organization  of 
behavior  in  designed  classes.  However,  the  immediate  focus  of 
these  approaches  generally  fell  upon  the  current  problem. 
Research  needs  to  be  directed  toward  uncovering  criteria  for 
organizing  knowledge  in  a  manner  that  facilitates  reusability 
for  potential  applications.  What  level  of  generality  should 
be  placed  into  abstract  classes?  At  what  level  in  a  hierarchy 
should  abstract  classes  give  way  to  concrete  classes?  Should 
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consideration  of  potential  subclasses  influence  the  design  of 
concrete  classes?  What  criteria  should  determine  which 
behaviors  define  a  class  of  objects,  and  how  do  these  criteria 
influence  reusability? 

3 .  Knowledge  Allocation 

It  was  suggested  in  Chapter  V  that  structured 
techniques  can  be  used  to  improve  the  implement  a,  ton  of  00 
methods.  However,  recommendations  for  accomplishing  this  were 
scrupulously  avoided.  R.esearch  needs  to  be  directed  at 
uncovering  criteria  for  using  the  results  of  such  techniques 
to  improve  00  design.  In  particular,  it  may  prove  fruitful  to 
investigate  whether  criteria  other  than  behavioral 
correspondence  (behavior  to  real-world  object)  should 
influence  the  allocation  of  behaviors  in  a  hierarchy. 

4 .  Functional  Decomposition 

Chapter  IV  analyzed  the  design  practice  of  subclass 
responsibility  as  a  subset  of  techniques  descended  from 
functional  decomposition.  Heuristics  were  suggested  for 
designing  subclass  responsible  behaviors.  Further 
investigation  should  be  conducted  into  the  potential 
vulnerabilities  of  hierarchy  designs  which  use  functional 
decomposition  techniques  to  uncover  and  organize  subclass 
responsible  behaviors.  In  particular,  the  ways  in  which 
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hierarchy  modifications  can  expose  such  designs  to  unexpected 
errors  merits  research. 

B.  CONCLUSIONS 

The  00  paradigm  represents  a  new  perspective  on  the 
practice  of  developing  software.  It  arrives  with  a  complement 
of  concepts,  tools,  and  theories  which  permits  developers  to 
organize  their  thinking  in  a  fashion  which  parallels  the 
manner  in  which  humans  develop  and  compose  knowledge  about  the 
real  world.  As  experience  with  the  00  approach  progresses, 
the  realization  grows  that  the  greatest  gains  occur  in  the 
areas  of  analysis  and  design:  intelligent,  coherent 

application  of  00  concepts  during  these  p  ases  of  development 
substantially  reduces  the  effort  and  costs  associated  with 
programming  and  maintenance. 

Though  the  00  paradigm  promises  much,  the  absence  of 
conceptual  continuity  and  standardization  has  so  far  resulted 
in  a  multiplicity  of  distinctly  diverse  OOPLs  and  development 
strategies.  This  thesis  has  attempted  to  formulate  an 
understanding  of  fundamental  00  concepts  (Chapter  II)  and  the 
tradeoffs  involved  in  applying  those  concepts  (Chapter  IV) . 
Such  a  foundation  should  serve  to  facilitate  analysis/design 
practices  (Chapter  III  and  Chapter  IV)  which  realize  the  many 
benefits  attributable  to  OO  development  (Chapter  I) . 

Particular  attention  has  been  drawn  to  inheritance  as  a 
vehicle  for  organizing  knowledge.  Inheritance  smartly 
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applied  is  a  powerful  mechanism  for  reusability.  It  is  the 
position  of  the  author  that  among  the  strategies  which  can  be 
employed  to  construct  inheritance  hierarchies,  the  safest  and 
conceptually  most  appropriate  course  lies  in  identifying  class 
hierarchies  with  type  hierarchies.  This  allows  the  compiler 
to  perform  optimization  operations,  and  forces  some  form  of 
semantic  consistency/structure  on  the  inheritance  hierarchy. 
In  this  setting,  developers  also  need  to  converge  on  a 
practicable  definition  of  specialization. 

While  inheritance  promotes  programming  economy  through 
reusability,  the  single  most  important  aspect  to  OOP  (or  any 
programming  methodology)  is  information  hiding.  Information 
hiding  shields  designers  from  their  own  mistakes  while 
concomitantly  reducing  the  effort  expended  in  uncovering  and 
correcting  mistakes.  Designers  utilizing  inheritance  must 
understand  and  account  for  inheritance/information  hiding 
tradeoffs.  Negligence  in  this  regard  can  only  lead  to  long- 
run  maintenance  difficulties  and  attendant  cost  increases. 
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APPENDIX  A.  C++  CODE 


A.  C++  CLASS  DEFINITIONS 


fifndef  CLKRAD_HPP 
tdefine  CLKRAD  HPP 


const  am 
const  fm 
const  true 
const  false 
const  off 
const  on 


0 

1 

1 

0 

0 

1 


//define  switch  values 


class  x_y_posit  { 

int  x;  //Cartesian  reference  system 

int  y; 
public : 

x_y^osit  (int  x_pos  =  0,  int  y_pos  =  0)  {x  =  x_pos; 
y  =  y_pos; } 

x_y_posit  operator= (x_y_posit ) ; 
void  display_jposition  ( )  ;  }; 

class  time  { 

int  hours;  //military  time 

int  minutes; 
int  seconds; 
public : 

time  () {hours  =  0;  minutes  =  0;  seconds  =  0;} 
time  (int  hrs,  int  mins,  int  secs) {hours  =  hrs; 

minutes  =  mins; 
seconds  =  secs;} 

void  change_time  (time) ; 
time  operator^ (t ime) ; 
void  display_t ime ( ) ;  ); 


class  radio  { 

x_y_posit  radio_location; 
int  radio_powered; 

int  radio_on; 

float  fm_station; 

float  am_station; 

int  am  fm  switch; 

float  volume  level; 


/ / can  be  implemented  many 
//true  equals  powered 
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public : 
radio 
void 
void 
void 
void 
void 
void 
void 
void 
void 
void 
void 
void 
void 
void 
void 
void 

}; 


(x_y_jposit)  ; 

change_radio_position  (x_y_posit) 

power_radio  ()  ; 

remove_radio_power () ; 

turn  radio  on  ()  ; 

turn_radio_of f () / 

increase_volume  () ; 

decrease  volume  (); 

select_am ( ) ; 

select_fm ( ) / 

select_am_stat ion  (float) / 
select_fm_station  (float) ; 
display_radio_on_of f  state  (); 
display_volume_level  (); 
display_am_channel  () ; 
display_fm_channel  () ; 
display_radio_jJosition  ()  ; 


class  elect ric_clock  { 

x_y_jposit  clock_location; 
int  clock_powered; 

int  clock_alarm; 

time  current_time; 

time  clock_alarm_time/ 

public : 

elect ric_clock  (x_y_posit) ; 

void  change_clock_jposition  (x_y_posit)  ; 

void  power  clock  ( )  ; 

void  remove_clock_power ( ) ; 

void  reset_clock_time (time) ; 

void  clock_alarm_on  (); 

void  clock_alarm  off  () ; 

void  aet_clock_alarm  time  (time) ; 

void  display_clock_alarm__time  (); 

void  display_clock_time  (); 

void  display_clock_jposition  ()  ; 

~electric_clock  (); 

}; 
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class  clock_radio  :  public  radio,  public  elect ric_clock  { 
int  clock_radio_pov7ered; 

time  radio  alarm_time; 
int  radio_alarm; 

pub lie: 

clock  radio (x  y  posit); 

void  change_clk_rad__position  (x_y_jposit )  ; 

void  power_clock_radio ( ) ; 

void  remove_clock_radioj»ower  ( )  ; 

void  set_radio_alarm_time (t ime  t) ; 

void  radio_alarm_on ( ) ; 

void  radio_alarm_of f () ; 

void  display_radio_alarm  on  off  state  (); 
void  display_radio_alarm_time  (); 
void  display_clock_radio_posit ion  (); 

}  ; 


class  composite_clock_radio  { 

electric_clock  clock_one;  //"part_of" 

radio  radio_one;  //"part_of" 

x_y_posit  comp_clk_rad_position;~ 

int  comp_clk_rad_powered; 

int  comp_radio_alarm; 

time  comp_radio_alarm_time; 

public : 

composite_clock_radio  (x  y_posit) ; 

void  power_comp_clock_radio () ; 

void  remove_comp_clock_radio_j>ower  ()  ; 

void  change_comp__clk_rad_posit ion  (x_y_posit)  ; 

void  turn_comp_radio_on  (); 

void  turn_comp_radio_of f  (); 

void  increase_comp_radio_volume  (); 

void  decrease_comp  radio  volume  ( ) ; 

void  select_am_stat ion  (float) ; 

void  select_fm_station  (float) ; 

void  select_am  (); 

void  select_fm  (); 

void  reset_comp_clock_t ime (time  t)  ; 

void  comp_clock_alarm_on  () ; 

void  comp_clock_alarm  off  (); 

void  comp_radio_alarm  on  (); 

void  comp_radio_alarm_^of  f  ( >  ; 

void  set_radio_alarm_t ime  (time) ; 

void  set_comp_clock_alarm  time  (time); 
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void  display_comp_clock_alarm_t ime  (); 
void  display_Cwra]^_clock_time  (); 
void  display_comp_radio_on_of f_state  (); 
void  display_comp_radio_volume_level  (); 
void  display_comp_radio_atn_channel  ( )  ; 
void  display_comp_radio_fm_channel  (); 


#endif  CLKRAD_HFF 

B.  X_Y_POSIT  CLASS  METHODS 

X  y  posit  X  y  posit :: operator= (x  y  posit  xy) 

{ 

X  =  xy.x; 
y  =  >:y.y; 
return  *this; 


void  x_y_posit : : display_posit ion  () 

cout  <<  "The  XY  position  is  X:"  <<  x  <<  "  Y:"  << 
<<  "An"; 

} 

C,  TIME  CLASS  METHODS 

void  t ime : : change_time  (time  t) 

{ 

if  (  (hours  >=  0)  &&  (hours  <=  24) ) 
hours  =  t. hours; 
else 

hours  =  0; 

if  ( (minutes  >=  0)  &&  (minutes  <=  60) ) 
minutes  =  t. minutes; 
else 

minutes  =  0; 

if  ((seconds  >=  0)  &&  (seconds  <=  60)) 
seconds  =  t. seconds; 
else 

seconds  =  0; 
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time  t ime : : operator= (t ime  t) 

{ 

change_time (t) ; 
return  *this; 


void  time : : display_time  () 

{ 

cout  <<  "The  time  is  "  <<  hours  <<  " : "  <<  minutes  << 
<<  seconds  <<  "\n"; 


D.  RADIO  CLASS  METHODS 

radio radio (x  y  posit  initial_posit ion) 
radio  location (initial_position) 


radio_powered  = 

false; 

radio  on  = 

off  ; 

fm  station  = 

8  8  .  0  ; 

am  station  = 

55.0; 

am  fm  switch  = 

fm; 

volume  level  = 

1.0; 

void  radio  ::  change_radio_jposition  (x_y_posit 
new_posit ion) 

{ 

radio_locat ion  =  new_f osition; 

) 


void  radio :: power_radio ( ) 

{ 

radio_powered  =  true; 

} 


void  radio ::  remove_radio_jpower  ( ) 

{ 

radio_jpowered  =  false; 
radio  on  =  off; 
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void  radio: :turn  radio  on  () 

{ 

radio_on  =  on; 

} 


void  radio :: turn_radio  off  () 

{ 

radio_powered  =  false; 

} 


void  radio increase  volume  () 

{ 

volume_level  *=  2.0; 

) 


void  radio :: decrease  volume  () 

{ 

volume_level  *=  0.5; 

} 


void  radio :: select  am() 

{ 

am_fm_switch  =  am; 

) 


void  radio :: select  fm() 

{ 

am_fm_s witch  =  fm; 

) 


void  radio :: select  am  station  (float 

int  valid_entry  =  false; 
while  ( ! valid_entry ) 

{ 

if  ((55.0  <=  channel)  (channel 

{ 

valid_entry  =  true; 
am_station  =  channel; 

) 


channel) 


<=  160.0)) 
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else 

{ 

cout  <<  "Invalid  entry,  try  again  between  55  and 
160  khz.\n" 
cin  >>  channel; 

}  //endif 
}  //endwhile 

} 


void  radio :: select_fm_stat ion  (float  channel) 

{ 

int  valid_entry  =  false; 
while  ( ! valid_entry) 

{ 

if  ((88.0  <=  channel)  &<i  (channel<=  108.0)) 

{ 

valid  entry  =  true; 
fm_station  =  channel; 

} 

else 

{ 

cout  <<  "Invalid  entry,  try  again  between  88  and 
108  inhz\n"; 
cin  >>  channel; 

}  //endif 
}  //endwhile 

) 


void  radio ::  display__radio  on  off_state  () 

{ 

cout  <<  "The  radio  is  "  <<  radio_on  <<  ".\n"; 

} 


void  radio :: display_volume_level  () 

{ 

cout  <<  "The  radio  volume  is  "  <<  volume_level 
<<  ".\n"; 

} 
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void  radio :: display  am  channel  () 

{ 

cout  <<  "The  am  station  is  "  <<  am_station  <<  ".\n"; 

} 


void  radio :: display_fm_channel  () 

{ 

cout  <<  "The  fm  station  is  "  <<  fm_station  <<  ".\n"; 

} 


void  radio :: display  radio_posit ion  () 

{ 

radio_locat ion . display_posit ion ( ) ; 

} 

E.  ELECTRIC_CLOCK  CLASS  METHODS 

electric_clock : : electric_clock  (x_y_posit 
initial_position)  :  clock_location  (initial^osition) , 
current_t ime ( ) ,  clock_alarm_time ( ) 

clock_j3owered  =  false/ 

clock_alarm  =  off/ 

} 


void  electric_clock  :  :  change_clock_posit  ion  (x_y_jposit 
new_j3osition) 

( 

clock_locat  ion  =  new_j3osition/ 


void  electric_clock : : power_clock  () 

f 

clock_powered  =  true/ 

) 


void  electric_clock : : remove_clock_power ( ) 
clock_powered  =  false/ 

) 
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void  electric_clock : : reset_clock_t ime (t ime  t) 

{ 

current  time  =  t; 

} 


void  electric_clock : : clock_alarm_on ( ) 

{ 

clock_alarm  =  on; 

) 


void  electric  clock: :clock  alarm  off () 
( 

clock_alarm  =  off; 

) 


void  electric_clock : : set_clock_alarm_time (time  t) 

{ 

clock_alarm_t ime  =  t; 

} 


void  electric_clock : :display_clock_ilarm_time  () 

{ 

clock_alarm_t ime . display_t ime () ; 

} 


void  elect ric_clock :: display_clock_t ime  () 

{ 

current_t ime . display  time(); 

} 


void  electric_clock : : display_clock_position  () 
clock_location . display_position ( ) ; 

} 
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F.  CLOCK_RADIO  CLASS  METHODS 

clock_radio : : clock_radio  (x_y_posit  init ial_position) 
radio ( init ial_pos it  ion)  ,  elect ric_clock 
(initial  position),  radio_alarm  time  (), 

clock  radio  powered  =  false; 
radio_alarm  =  off; 

) 


void  clock_radio :: change 
new_position) 
f 

change_clock_posit ion 
change_radio_posit ion 

) 


elk  rad_position  (x_y_posit 


(new  position) ; 
(new  position) ; 


void  clock_radio : : power_clock_radio  () 

{ 

power_clock  (); 
power  radio  (); 


void  clock_radio : : remove_clock_radio_power  () 

{ 

remove_clock_power  (); 
remove_radio_power  (); 

} 


void  clock_radio : : set_radio_alarm_time  (time  t) 

{ 

radio_alarm_t ime  =  t; 

} 


void  clock  radio:: radio  alarm  on  () 

{ 

radio_alarm  =  on; 

} 
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void  clock_radio  :  :  radio_alarni_of  f  () 

{ 

radio  alarm  =  off; 

} 


void  clock_radio : : display_radio_alarm_on_of f_state  () 

{ 

cout  <<  "The  radio  alarm  is  "  <<  radio_alarm  <<  ".\n"; 

} 


void  clock_radio : : display_radio_alarm_time  () 

{ 

radio_alarm_time . display_time () ; 

} 


void  clock_radio : : display_clock_radi  position  () 
display_clock_position () ; 

} 

COMPOS ITE_CLOCK_RADIO  CLASS  METHODS 

composite_clock_radio : : composite_clock_radio  (x_y_posit 
init ial^osit ion)  :  clock_one  (initial_position)  , 
radio_one  (initial_position) ,  comp_radio_alarm_time  () 

{ 

comp_clk_rad_powered  =  off;  //false  equals  off 
comp_radio_alarm  =  off;  //false  equals  off 

} 


void  composite_clock_radio : :power_comp_clock_radio  () 

{ 

comp_clk_rad_powered  =  true; 
radio_one . power_radio  (); 
clock_one . power_clock  (); 


void  composite_clock_radio : : remove_comp_clock_radio_power  () 

{ 

comp_clk_rad_powered  =  false; 
radio  one. power  radio  (); 
clock  one. power  clock  ();  ) 


void  composite  clock  radio :: change_comp_clk_rad_jposit ion 
(>:_y_posit  new_posit ion) 

{ 

comp  clk_rad_posit ion  =  new_posit ion ; 
radio_one . change_radio_position  (new_position) ; 
clock  one . change  clock j>osit ion  (new_position) / 


void  composite_clock_radio : : turn_comp_radio_on  () 

{ 

radio_one . turn_radio_on  (); 

}  _ 


void  composite_clock  radio :: turn_comp_radio_off  () 

{ 

radio_one . turn_radio_of f  (); 


void  composite_clock  radio :: increase_comp_radio_volume  () 

{ 

radio_one . increase_volume  () ; 

} 


void  composite_clock_radio : : decrease_comp_radio_volume  () 

{ 

radio_one . decrease_volume  (); 

} 


void  composite_clock  radio :: select_am_stat ion  (float 
channel ) 

( 

radio  one . select  am  station  (channel); 

} 


void  composite_clock_radio : : select_fm_station  (float 
channel ) 

{ 

radio_one . select  fm  station  (channel); 
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void  composite_clock_radio : :select_am() 

{ 

radio_one . select_am  (); 

} 


void  composite  clock_radio : : select_fm  () 

{ 

radio_one . select_fm  ( ) ; 

} 


void  composite  clock_radio : : reset_comp_clock_t ime (time  t) 

{ 

clock_one . reset_clock_t ime (t ) ; 

)  ” 


void  composite_clock_radio : : comp_clock_alarm_on  () 

{ 

clock__one  .  clock_alarm_on  ()  ; 

} 


void  composite_clock_radio : : comp_clock_alarm_of f  () 

{ 

clock_one . clock_alarm_of f  (); 

) 


void  composite_clock_radio : : comp_radio_alarm_on () 

{ 

comp  radio_alarm  =  on; 

} 


void  composite_clock_radio : : comp_radio_alarm_of f () 

{ 

comp_radio_alarm  =  off; 

} 


void  composite_clock_radio : : set  radio_alarm_t ime  (time  t) 

{ 

comp_radio_alarm  time  =  t; 

)  ~  ~  ~ 
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void  coinposite_clock_radio  :  :  set_comp_clock_alarm_time 
(time  t) 

{ 

clock_one . set_clock_alarm_t ime  (t) ; 

} 


void  compos ite_clock_radio :: display_comp_clock_alarm_t ime  () 

{ 

clock  one . display_clock  alarm_time  ()/ 

}  _ 


void  composite_clock  radio :: display_comp_clock_t ime  () 
clock_one  .  display__clock_time  ()  ; 

} 


void  composite  clock  radio :: display_comp_radio_on  off_state  () 
f 

radio_one  display_radio_on_of f_state  () ; 

) 


void  composite_clock_radio : : display_comp_radio_volume_level  () 

{ 

radio_one . display_volume_level  () ; 

} 


void  composite_clock_radio : : display_comp_ radio_am_channel  () 

{ 

radio_one . display_am_channel  () ; 

} 


void  composite_clock_radio : : display_comp_radio_fm_channel  () 

{ 

radio_one . display_fm_channel  () ; 

) 
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APPENDIX  B.  SMALLTALK  CODE 


SMALLTALK  CLASS  DEFINITIONS 

object  subclass:  fXyPosit 

instanceVariableNames :  '  x  y  ' 

classVariableNames :  '' 

poolDictionaries :  '' 

object  subclass:  tSimpleTime 

instanceVariableNames:  '  hours  minutes  seconds 
classVariableNames:  '' 
poolDictionaries:  '' 

object  subclass:  #Radio 

instanceVariableNames:  '  radioLocat ion  radioPower 
radioOn  fmStation  amStation  amfmSwitch 
volumeLevel  ' 

ClassVariableNames:  '' 
poolDictionaries:  '' 

radio  subclass:  #ElectricCloc)c 
instanceVariableNames:  '  clockPowered  c-ocJcAlarm 
currentTime  clockAlarmTime  ' 
ClassVariableNames:  '' 
poolDictionaries:  '' 

electric_clock  subclass:  #ClockRadio 

instanceVariableNames:  '  clockRadioPowered 
radioAlarmTime  radioAlarm  ' 
classVariableNames:  ’’ 
poolDictionaries:  '' 

object  subclass:  #CompositeClockRadio 

instanceVariableNames:  '  clockOne  radioOne 

compClockRadioPosit ion  compClockRadioPowered 
radioAlarmTime  radioAlarm  ' 
ClassVariableNames:  '' 
poolDictionaries: 


B.  XYPOSIT  CLASS  METHODS 


setx:  xpos  sety:  ypos 
X  : =  xp . 

y  :=yp- 

displayPosition 

I  input  output  char | 

input  :=  Readstream  on:  'The  XY  position  is  X:%  Y:&'. 
output  :=  Writestream  on:  String  new. 

[input  atEnd] 

whileFalse:  [(char  :=  input  next)  =  $% 
ifTrue:  [x  printOn:  output] 
ifFalse;  [(char  =  $&) 

ifTrue:  [y  printOn:  output] 
ifFalse:  (output  nextPut :  char]]]. 

''output  contents 

C.  SIMPLETIME  CLASS  METHODS 

changeTimeHours :  hrs  minutes:  mins  seconds:  secs 
hours  : =  hrs . 
minutes  :=  mins, 
seconds  :=  secs. 

displayTime 

I  input  output  char ) 

input  :=  Readstream  on:  'The  time  is 
output  :=  Writestream  on:  String  new. 

[input  atEnd] 

whileFalse:  [(char  :=  input  next)  =  $% 
ifTrue:  [hours  printOn:  output] 
ifFalse:  [(char  ==  $&) 

ifTrue:  [minutes  printOn:  output] 
ifFalse;  [(char  =  $#) 

ifTrue:  [seconds  printOn:  output] 
ifFalse:  [output  nextPut :  char]]]] 

''output  contents 

D.  RADIO  CLASS  METHODS 

initialize:  init ialPosition 

radioLocat ion  :=  XyPosit  new. 
radioLocat ion  :=  init ialPosition . 
radioPowered  :=  'false'. 
radioOn  :=  'off'. 

fmStation  :=  88.0. 

amStation  :-  55.0. 

amfmSwitch  :=  'am' . 
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volumeLevel 


1.0. 


changeRadioPosit ion :  newPosition 
radioLocation  :=  newPosition. 

powerRadio 

radioPowered  :=  'true'. 

removeRadioPower 

radioPowered  :=  'false' . 

turnRadioOn 

(radioPowered  =  'true') 

ifTrue:  [radioOn  :=  'on']. 

t urnRadioOf  f 

radioOn  :=  'off'  . 

increaseVolume 

volumeLevel  : =  volumeLevel  *  2.0. 
decreaseVolume 

volumeLevel  :=  volumeLevel  *  0.5. 
selectAm 

amfmSwitch  :=  'am'. 
selectFm 

amfmSwitch  : =  ' fm'  . 

selectAmStat ion :  channel 

(channel  >=  55.0  and:  [channel  <=  160.0]) 
ifTrue:  [amStation  :=  channel]. 

selectFmStat ion :  channel 

(channel  >=  88.0  and:  [channel  <=  108.0]) 
ifTrue:  [fmStation  :=  channel]. 

displayRadioOnOf  f St ate 
''radioOn 

display VolumeLevel 
''volumeLevel 

displayAmChannel 

^amStation 

display_fm  channel 
''fmStation 
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display_radio_posit ion 

^radioLocat ion  displayPosit ion . 

E.  ELECTRICCLOCK  CLASS  METHODS 


initialize:  intial 
super  initializ 
clockPowered 
clockAlarm 
currentTime 
current Time 

clockAlarmTime 
clock  alarmTime 


changed  ockP  os  it  io 
RadioLocat ion  : 


osit ion 

:  init ialPosit ion . 

' false' . 

:=  '  off'  . 

:=  time  new. 

:=  changeTimeHours : 

seconds:  0 
:=  time  new. 

:=  changeTimeHours: 
seconds :  0 

:  newPosition 
newFosit ion . 


powerClock 

clockPowered  :=  'true'  . 


removeClockPower 

clockPowered  :=  'false'. 

resetClockTime :  newTime 
currentTime  :=  newTime. 


clockAlarmOn 

clockAlarm  :=  'on'  . 


clockAlarmOf  f 

clockAlarm  :=  'off' . 

setClockAlarmTime :  newAlarmTime 
clockAlarmTime  :=  newAlarmTime. 

displayClockAlarmTime 

''clockAlarmTime  displayTime. 

displayClockTime 

^currentTime  displayTime. 

display_clock_posit ion 

''radioLocat  ion  displayPosit  ion  . 


0  minutes :  0 

0  minutes :  0 


]  4":' 
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CLOCKRADIO  CLASS  METHODS 


initialize:  initialPosit ion 

super  initialize:  initialPosit ion . 
clockRadioPowered  :=  'false'  . 
radioAlarmTime  :=  SimpleTime  new. 
radioAlarmTime  changeTimeHours :  0  minutes:  0 

seconds:  0 

radioAlarm  :=  'off' . 

changeClkRadPosit ion :  newPosition 

self  changeRadioPosition :  newPosition. 

powerClockRadio 

clockRadioPowered  :=  'true', 
self  powerRadio. 
self  powerClock. 

removed  ockRadioP  owe  r 

clockRadioPowered  :=  'false', 
self  removeRadioPower . 
self  removeClockPower . 
self  turnRadioOf f . 

setRadioAlarmTime :  newTime 
radioAlarmTime  :“  newTime. 

radioAlarmOn 

radioAlarm  :=  'on' . 

radioAlarmOf  f 

radioAlarm  :=  'off' . 

displayRadioAlarmOnOf fState 
''radioAlarm 

displayRadioAlarmTime 

^radioAlarmTime  displayTime. 

di splayClockRadioPosit ion 

"'self  displayRadioPosition . 

G.  COMPOSITECLOCKRADIO  CLASS  METHODS 

initialize:  init ialPosition 
radioOne  :=  Radio  new. 

radioOne  initialize:  initialPosit ion . 
clockOne  ;=  Elect ricClock  new. 
clockOne  initialize:  initiaiPosition . 
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compClockRadioPosit ion  :=  XyPosit  new. 
compClockRadioPosit ion  :=  init ialPosit ion 
compClockRadioPowered  :=  'false'. 
radioAlarmTime  :=  SimpleTime  new. 

radioAlarmTime  changeTimeHours :  0  minutes 
seconds :  0 

radioAlarm  :=  'off'. 

powerCompClockRadio 

clockOne  powerClock. 
radioOne  powerRadio. 
compClockRadioPowered  :=  'true'. 

removeCompClockRadioPower 

clockOne  removeClockPower . 
radioOne  removeRadioPower . 
compClockRadioPowered  :=  'false' . 

changeCompClkRadPosition :  newPosition 

clockOne  changeClockPosit ion :  newPosition 
radioOne  changeRadioFosit ion ;  newPosition 
compClockRadioPosit ion  :=  newPosition. 

turnCompRadioOn 

radioOne  turnRadioOn. 

turnCompRadioOf f 

radioOne  turnRadioOf f . 

increaseCompRadioVolume 

radioOne  increaseVolume . 

decreaseCompRadioVolume 

radioOne  decreaseVolume . 

selectAmStat ion :  channel 

radioOne  selectAmStat ion :  channel. 

select_fm_stat ion :  channel 

radioOne  selectFmStation :  channel. 

selectAm 

radioOne  selectAm. 

selectFm 

radioOne  selectfm. 

resetCompClockTime :  newTime 

clockOne  resetClockTime :  newTime. 
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compel ockAlarmOn 

clockOne  clockAlarmOn . 

compClockAlarmOf f 

clockOne  clockAlarmOf f . 

compRadioAlarmOn 

radioAlarm  :=  'on'  . 

compRadioAlarmOf f 

radioAlarm  :=  'off' . 

setRadioAlarmTime :  newTime 

radioAlarmTime  :=  newTime. 

setCompClockAlarmTime :  newTime 

clockOne  setClockAlarmTime :  newTime. 

di splay Compel ockAlarmTime 

''clockOne  displayClockAlarmTime  . 

displayCompClockTime 

''clockOne  displayClockTime . 

displayCompRadioOnOff State 

''radioOne  displayRadioOnOf fState . 

displayCompRadioVolumeLevel 

''radioOne  displayVolumeLevel . 

displayCompRadioAmChannel 

''radioOne  displayAmChannel . 

displayCompRadioFmChannel 

''radioOne  displayFmChannel . 

displayCompClockRadioPosition 

''compClockRadioPosition  displayPosition . 
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APPENDIX  C.  CLOS  CODE 


A.  CLOS  CLASS  DEFINITIONS 

(defclass  x_y_posit  () 

( (x  :initform  0  :type  integer) 

(y  linitform  0  :type  integer))) 

(defclass  time  () 

((hours  rinitform  0  :type  integer) 

(minutes  :initform  0  :type  integer) 

(seconds  rinitform  0  :type  integer))) 

(defclass  radio  () 

( (radio_location  rinitform  (make-instance 
' x_y_posit ) ) 

( radio_powered  rinitform  "false") 

(radio_on  rinitform  "off"  rtype  string) 

(fm_station  rinitform  88  rtype  float) 

(am_station  rinitform  55  rtype  float) 

(am_fm_switch  rinitform  "off"  rtype  string) 
(volume_level  rinitform  1.0  rtype  float))) 

(defclass  electric_clock  () 

( (clock_location  rinitform  (make-instance 
'  ) ) 

(clock_powered  rinitform  "false"  rtype  string) 
(clock_alarm  rinitform  "off"  rtype  string) 

(current  time  rinitform  (make-instance  'time)) 
(clock_alarm_t ime  rinitform  (make-instance  'time))) 

(defclass  clock_radio  (radio  electric_clock) 

( (clock_radio_powered  rinitform  "false"  rtype  string) 
(radio_alarmt ime  rinitform  (make-instance  'time)) 
(radio_alarm  rinitform  "off"  rtype  string))) 

(defclass  compos it e_clock_radio  () 

( (clock_one  rinitform  (make-instance 
' electric_clock) ) 

(radio_one  rinitform  (make-instance  'radio)) 
(comp_clk_rad_positon  rinitform  (make- instance 
x_y_posit ) ) 

(comp_clk_rad_powered  rinitform  "false"  rtype 
string  ) 

(comp_radio  alarm  rinitform  "off"  rtype  string) 
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(comp_radio_alarin_time  rinitform  (make-instance 
' time) ) ) 

B.  X_y_POSIT  CLASS  METHODS 

(defmethod  change_xyvals  ( (p  x_y_posit)  xpos  ypos) 
(setf  (slot-value  p  ' x)  xpos) 

(setf  (slot-value  p  'y)  ypos)) 

(defmethod  display^osition  (  (p  x_y_posit)  ) 

(format  t  "Current  XY  position  is  X:~a  Y:~a." 
(slot-value  p  'x) 

(slot-value  p  ' y) ) ) 

C.  TIME  CLASS  METHODS 

(defmethod  change_time  ( (tt  time)  hrs  mins  secs) 

(setf  (slot-value  tt  'hours)  hrs) 

(setf  (slot-value  tt  'minutes)  mi-  t) 

(setf  (slot-value  tt  'seconds)  se  5)) 

(defmethod  display_time  ( (tt  time) ) 

(format  t  "The  time  is  ~a:~a:~a," 

(slot-value  tt  'hours) 

(slot-value  tt  'minutes) 

(slot-value  tt  'seconds))) 

D.  RADIO  CLASS  METHODS 

(defun  make-object-radio  () 

(make- instance  'radio)) 

(defmethod  change_radio_posit ion  ( (r  radio)  xpos  ypos) 
(with-slots  (radio_location)  r 
(change_xyvals  radio_locat ion  xpos  yj:  s) 

(defmethod  power_radio  ( (r  radio) ) 

(with-slots  (radio^owered)  r 
(setf  radio_powered  "true"))) 

(defmethod  remove_radio_jpower  (  (r  radio)  ) 

(with-slots  (radio_powered)  r 
(setf  radio_powered  "false'))) 

(defmethod  turn_radio_on  ( (r  radio) ) 

(with-slots  (radio  on)  r 


150 


(setf  radio  on  "on"))) 

(defmethod  turn_radio  off  ( (r  radio) ) 

(with-slots  {radio_on)  r 
(setf  radio_on  "off"))) 

(defmethod  increase_volume  ( (r  radio) ) 

(with-slots  ( volume_level )  r 
(setf  volume_level  (*  volume_level  2.0)))) 

(defmethod  decrease_volume  ( (r  radio) ) 

(with-slots  ( volume_level )  r 
(setf  volume_levGl  (*  volume_level  .5)))) 

(defmethod  select_am  ( (r  radio) ) 

(with-slots  (am  fm  switch)  r 
(setf  am  fm  switch  "am"))) 

(defmethod  select  fm  ( (r  radio) ) 

(with-slots  (am_fm_switch)  r 
(setf  am_fm_switch  "fm"))) 

(defmethod  select_am_station  ( (r  radio)  channel) 
(with-slots  (am_station)  r 
(setf  am_station  channel) ) ) 

(defmethod  select_fm_station  ( (r  radio)  channel) 
(with-slots  (fm_station)  r 
(setf  fm_station  channel) ) ) 

(defmethod  display_radio_on_of f_state  ( (r  radio) ) 
(format  t  "The  radio  is  ~A." 

(slot-value  r  ' radio_on) ) ) 

(defmethod  display_volume_level  ( (r  radio) ) 
(format  t  "The  radio  volume  level  is  ~A. " 
(slot-value  r  ' volume_level ) ) ) 

(defmethod  display_am_channel  ( (r  radio) ) 

(format  t  "The  am  station  is  ~A. " 

(slot-value  r  'am  atation) ) ) 

(defmethod  display_fm_channel  ( (r  radio) ) 

(format  t  "The  fm  station  is  ~A. " 

(slot-value  r  ' fm_atation) ) ) 

(defmethod  display  radio  position  ((r  radio)) 
(with-slots  (radio_location)  i 
(display_posit ion  radio_location) ) ) 
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ELECTRIC  CLOCK  CLASS  METHODS 


E  . 


(defun  make-ob ject-electric_clock  () 

(make-instance  ' electric_clock) ) 

(defmethod  change_clock_position  ( (ec  electric_clock) 
xpos  ypos) 

(with-slots  (clock_location)  ec 
(change_xyvals  clock_locat ion  xpos  ypos) ) ) 

(defmethod  power_clock  ( (ec  electric_clock) ) 

(with-slots  (clock_powered)  ec 
(setf  clock_powered  "true"))) 

(defmethod  remove_clock_power  ( (ec  electric_clock) ) 
(with-slots  (clock  powered)  ec 
(setf  clock  powered  "false"))) 

(defmethod  reset_clock_time  ( (ec  electric_clock)  hrs 
mins  secs) 

(with-slots  (current_t ime)  ec 
(change_time  current_time  hrs  mins  secs) ) ) 

(defmethod  clock_alarm_on  ( (ec  electric_clock) ) 
(with-slots  (clock_alarm)  ec 
(setf  clock_alarm  "on") ) ) 

(defmethod  clock_alarm_of f  ( (ec  electric_clock) ) 
(with-slots  (clock_alarm)  ec 
(setf  clock_alarm  "off"))) 

(defmethod  set_clock_alarm_time  ( (ec  electric_clock)  hrs 
mins  secs) 

(with-slots  (clock_alarm_time)  ec 
(change_time  clock_alarm_time  hrs  mins  secs)  )  ) 

(defmethod  display  clock  alarm_time  ( (ec 
electric_clock) ) 

(with-slots  (clock_alarm_time)  ec 
(display_time  clock_alarm_time) ) ) 

(defmethod  display_clock  time  ( (ec  elect ric_clock) ) 
(with-slots  (current_time)  ec 
(display_t ime  cur_time) ) ) 

(defmethod  display_clock_location  ( (ec  electric_clock) ) 
(with-slots  (clock_location)  ec 
(display_posit ion  clock_locat ion ) ) ) 


CLOCK  RADIO  CLASS  METHODS 


F  . 


(defun  make-ob ject-clock_radio  () 

(make- instance  ' clock_radio) ) 

(defmethod  change_clk_rad_j>osit ion  ( (cr  clock_radio) 
xpos  ypos) 

(with-slots  (radio_location  clock_locat ion)  cr 
(change_xyvals  radio_location  xpos  ypos) 
(change_xyvals  clock_location  xpos  ypos))) 

(defmethod  power_clock_radio  ( (cr  clock_radio) ) 

( (setf  radio_powered  "true") 

(setf  clock^powered  "true") ) ) 

(defmethod  remove_clock_radio_power  ( (cr  clock_radio) ) 
((setf  radio_powered  "false") 

(setf  clock  powered  "false"))) 

(defmethod  set_radio__alarm_time  (  (cr  clock_radio)  hrs 
mins  secs) 

(with-slots  (radio_alarm_t ime)  cr 
(change_time  radio_alarm_time  hrs  mins  secs) ) ) 

(defmethod  radio_alarm_on  ( (cr  clock_radio) ) 
(with-slots  (radio_alarm)  cr 
(setf  radio_alarm  "on") ) ) 

(defmethod  radio_alarm_of f  ( (cr  clock_radio) ) 
(with-slots  (radio_alarm)  cr 
(setf  radio_alarm  "off"))) 

(defmethod  display_radio_alarm_on_of f_state  ( (cr 
clock_radio) ) 

(format  t  "The  radio  alarm  is  ~A." 

(slot-value  cr  ' radio_alarm) ) ) 

(defmethod  display_radio_alarm_time  ( (cr  clock_radio) ) 
(with-slots  (radio  alarm_time)  cr 
(display_time  radio_alarm_t ime) ) ) 

(defmethod  display  clock  radio_jposit ion  (  (cr 
clock_radio) ) 

(with-slots  (clock_location)  cr 
(display_position  clock_location) ) ) 
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G.  COMPOSITE_CLOCK_RADIO  CLASS  METHODS 

(defun  make-ob ject-composite_clock_radio  () 
(make-instance  ' composite_clock_radio) ) 

(defmethod  power_comp_clock_radio  ( (ccr 
composite_clock_radio) ) 

(with-slots  (comp_clk_rad_powered  clock_one  radio_one) 
ccr 

(setf  comp  clk_rad__powered  "true") 

(power_radio  radio_one) 

(power_clock  clock_one) ) ) 

(defmethod  remove_comp_clock_radio_power  ( (ccr 
composite_clock_radio) ) 

(with-slots  (comp  clk_rad  powered  clock_one  radio_one) 
ccr 

(setf  comp  clk_rad_powered  "false") 

(remove  radic_power  radio_one) 

(remove  clock_power  clock_one) ) ) 

(defmethod  change_comp_clk__rad_jposit ion  (  (ccr 
composite  clock_radio)  xpos  ypos) 

(with-slots  (radio_one  clock_one 
comp_clk_rad_position)  ccr 
(change_position  comp_clk_rad_position  xpos  ypos) 
(change_radio_position  xpos  ypos) ) ) 

(defmethod  turn_comp_radio_on  (  (ccr  radio) ) 
compos it e_clock_radio 
(with-slots  (radio_one)  ccr 
(turn_radio_on  radio_one) ) ) 

(defmethod  turn_comp_radio_of f  ( (ccr 
composite_clock_radio) ) 

(with-slots  (radio_one)  ccr 
(turn_radio_of f  radio_one) ) ) 

(defmethod  increase_comp_radio_volume  ( (ccr 
composite_clock_radio)  ) 

(with-slots  (radio_one)  ccr 
(increase_volume  radio_one) ) ) 

(defmethod  decrease_comp_radio_volume  ( (ccr 
composite_clock_radio) ) 

(with-slots  (radio_one)  ccr 
(decrease  volume  radio  one) ) ) 

(defmethod  select  am  station  ( (ccr 
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composite  clock_radio)  channel) 

(with-slots  (raclio_one)  ccr 
(slect_am_station  radio_one  channel) ) ) 

(defmethod  select_fm_station  ( (ccr 

composite  clock  radio)  channel) 

(with-slots  (radio_one)  ccr 
(select_fm_station  radio_one  channel))) 

(defmethod  select_am  ( (ccr  composite_clock_radio) ) 
(with-slots  (radio_one)  ccr 
(select_am  radio_one) ) ) 

(defmethod  select  fm  (  (ccr  composite_clock_radio) ) 
(with-slots  (radio  one)  ccr 
(select  fm  radio  one) ) ) 

(defmethod  reset_comp_clock_time  ( (ccr 

composite  clock  radio)  hrs  mins  secs) 

(with-slots  (clock_one)  ccr 
(reset_clock_t ime  clock_one  hrs  mins  secs) ) ) 

(defmethod  comp_clock_alarm_on  ( (ccr 
composite_clock_radio) ) 

(with-slots  (clock_one)  ccr 
(clock_alarm_on  clock_one) ) ) 

(defmethod  comp_clock_alarm_of f  ( (ccr 
composite_clock__radio)  ) 

(with-slots  (clock_one)  ccr 
(clock_alarm_of f  clock_one) ) ) 

(defmethod  comp_radio_alarm_on  ( (ccr 
composite  clock  radio) ) 

(with-slots  (comp_radio_alarm)  ccr 
(setf  comp_radio_alarm  "on”))) 

(defmethod  comp_radio_alarm_of f  ( (ccr 
composite_clock_radio) ) 

(with-slots  (comp_radio_alarm)  ccr 
(setf  comp_radio_alarm  "off"))) 

(defmethod  set_radio_alarm_t ime  ( (ccr 

composite_clock_radio)  hrs  mins  secs) 

(with-slots  (comp_radio_alarm_time)  ccr 
(change_time  comp  radio  alarm_time  hrs  mins  secs) ) ) 
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(defmethod  set  comp  clock_alarm_time  ( (ccr 
composite_clock  radio)  hrs  mins  secs) 
(with-slots  (clock_one)  ccr 
( set_clock_alarm_t ime  clock_one  hrs  mins  secs) ) ) 

(defmethod  display  comp  clock_alarm_t ime  ( (ccr 
composite_clock_radio) ) 

(with-slots  (clock_one)  ccr 
(display_clock_alarm_time  clock_one) ) ) 

(defmethod  display  comp_clock_alarm_time  ( (ccr 
composite_clock_radio) ) 

(with-slots  (clock_one)  ccr 
(display_clock  alarm  time  clock  one) ) ) 

(defmethod  display  comp  clock  time  ( (ccr 
composite_clock_radio) ) 

(with-slots  (clock__one)  ccr 
(display_clock_t ime  clock_one) ) ) 

(defmethod  display_comp_radio_on_of f  state  ( (ccr 
composite_clock_radio) ) 

(with-slots  (radio_one)  ccr 
(display_radio_on_of f_state  radio_one) ) ) 

(defmethod  display_comp_radio_volume_level  ( (ccr 
composite_clock_radio) ) 

(with-slots  (radio_one)  ccr 
(display_volume_level  radio_one) ) ) 

(defmethod  display_comp_radio__am_channel  (  (ccr 
composite_clock_radio) ) 

(with-slots  (radio_one)  ccr 
(display_am_channel  radio_one) ) ) 

(defmethod  display_comp_radio_fm_channel  ( (ccr 
composite_clock_radio) ) 

(display_fm_channel  radio  one) ) ) 


Iff"' 
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